Ratsky DevOps/OpenSource Hub

Субботний мем с полей Я тут хотел поменять привязку интернет эквайринга с самозанятости на ИП и получил самую крутую консультацию!

[SRE] Основная причина Основная причина инцидента - это дефект в ПО или ошибка человека, устранив которую, мы можем быть уверены: аналогичная ситуация больше не повторится. Частые причины: ⁃ Недостаточная автоматизация процессов ⁃ Ошибка в коде ⁃ Ошибка в тестировании Любую из этих причин важно найти и устранить, чтобы система становилась надёжнее!

[SRE] Оповещение (Алерт) Алерт - это сообщение, на которое должен обратить внимание человек. Они могут приходить в: тикет-системы, email, мессенджер или даже на пейджер (звонок). Типы алертов: ⁃ Тикет: не срочно — задача ставится “в очередь”, берётся в обычном порядке. ⁃ Вызов (пейдж): требуется немедленная реакция инженера. Правильная настройка алертов уменьшает стресс и делает работу SRE эффективнее!

[Разработка] Стратегии обмена в реальном времени Существуют четыре основные стратегии обмена данными между клиентом и сервером. Две из которых позволяют это делать в реальном времени. Стратегии обмена Long Polling - клиент отправляет запрос, сервер держит соединение открытым до ответа или до тайм-аута Short Polling - клиент периодически отправляет запрос для проверки обновлений WebSocket - работает поверх TCP, использует постоянное соединение SSE - push технология, причем связь инициализирует се...

Все подводят итоги года в канальчиках, а я не буду! Скажу так, я уверен, что все мы очень крутые, сильные и компетентные люди, которые не останавливаются на достигнутом и хотят большего! Но без пожеланий от меня не хочу вас оставлять, по этому -> Хочу пожелать всем становиться лучше во всем, делать то, что запланировали и хотите. Делать не смотря на трудности и лень. Быть проактивными, а не реактивными. Заботится о себе и близких, а после если останется ментальной и физической силы о других. Реа...

[Разработка] Про тестирование API Увяз я в своем новом проекте, сегодня писал тесты для API. Для меня это достаточно новая тема, поделюсь с вами полезными мыслями. Нужно ли тестировать API? Ответ очевиден - да. Но давайте поймем почему нужно тестировать API. API - один из важнейших программных компонентов системы. Это канал связи клиента с сервером ну или один микросервис с другим. Он управляет бизнес-процессами и предоставляет сервисы, которые приносят пользу пользователям. Есть такая пирамида ...

[SRE] Информационна панель Веб-приложение или отдельное приложение, где собирается сводная информация об основных показателях системы. Обычно на дашборде есть фильтры, селекторы, всё настраивается так, чтобы за пару секунд понять: “Система работает хорошо или нет?” Также есть вспомогательные дашборды: они показывают, например, количество обращений пользователей, кто сейчас дежурит или открытые инциденты. Хороший дашборд помогает моментально принимать решения и оперативно реагировать на проблемы!

[SRE] Мониторинг Стартуем серию про базовые понятия SRE. Коротко и по делу — лучше усвоится! Мониторинг (наблюдение) - это сбор, обработка, агрегирование и отображение количественных показателей работы системы. Фиксируем количество запросов, ошибок, время обработки, аптайм сервисов и серверов. Два метода мониторинга ⁃ Белый ящик: отслеживаем внутренние метрики — логи, обработки HTTP-запросов, статистику компонентов системы. ⁃ Черный ящик: наблюдаем внешнее поведение системы глазам...

[SRE] Как устроены дежурства Полностью стабильных приложений не бывает — поэтому SRE практики дежурств важны! Основные типы дежурств • Primary on-call — основной инженер, принимает инциденты первым, решает проблемы. • Secondary on-call — дублёр, подключается при необходимости или для менее критичных задач. • Follow-the-sun — смены по часовым поясам, чтобы избегать ночных дежурств и снижения стресса. • Разделение по времени суток — дневные и ночные/выходные дежурства, если ком...

[SRE] Рутина - убивца Дальше разберем вопрос - почему же лучше иметь меньше рутины? Ответ: рутина убивает и вгоняет в депрессию инженеров. На этом у меня все. Всем хорошего дня без рутины! Полезное правило А теперь когда мы знаем, что рутина это - зло и его нужно искоренять. Давайте узнаем интересное правило 50%. Стоит попробовать ввести порог 50% рутины. Мы внедряем это правило и отслеживаем показатель рутины инженеров. И стараемся не допустить превышения этого порога. А этот порог, генерирует ...