Что такое мониторинг?

Такой кажущийся очевидным вопрос, любой специалист тут же готов на него ответить. Но, что характерно, отвечают все по-разному. Для кого-то это некая "система", продукт конкретного вендора: prometheus, zabbix или что-то из этого ряда. Для кого-то это система графиков и оповещений, отражающая состояние дел в вашей инфраструктуре. Для кого-то некий "черный ящик" с которым "возятся девопсы"

Я представляю себе мониторинг как комплексную систему, назначение которой — повысить стабильность эксплуатируемой системы в целом за счет наблюдения за конкретными узлами этой системы. При помощи мониторинга мы должны мочь:

а) упредить аварию
б) получить нормальные уведомления об аварии, если она произошла
и) иметь актуальные данные о состоянии нашей системы

Система мониторинга также имеет такие характеристики как чувствительность, уровень шума и процент покрытия.

Разберемся подробнее
Анализируя данные, поставляемые мониторингом, мы можем понять, что что-то пошло не так, еще до того, как наблюдаемый узел начнет выходить из строя и среагировать до того, как произойдет отказ в обслуживании. Например, если некий сервер всегда потреблял 10% CPU, а сейчас вдруг начал потреблять 80%, то что-то, скорее всего, идет не так и когда уровень потребления дойдет до ста, то что-то упадет. Мы можем повесить алерт на критичный уровень и среагировать раньше.

Но что если это запустился некий контролируемый процесс (например после очередного релиза или начался пик трафика, в общем ситуация является нормальной и контролируемой)? Тогда мы все равно получим алерт, потратим время дежурного инженера на выяснение обстоятельств и, что самое неприятное, мы будем вынуждены либо отключить алерт, либо оставить его гореть. Обе эти ситуации довольно неприятные, так как искажают общую картину. В первом случае мы не получим уведомления, когда алерт сигнализирует о действительной проблеме, во втором случае мы получим "слепоту на алерты", когда просто перестанем обращать на него внимание. Нужно вводить метрику, растянутую по времени. То есть не "CPU > 80% тогда алерт", а "CPU > 80% в течении какого-то времени, тогда алерт". Но в этом случае мы должны знать об предстоящих пиках трафика или нагрузках на процессор. А вдруг паттерн аварии совпадет с нашими ожиданиями и алерта не будет? Надо вводить дополнительные условия: если CPU > 80% и растет, а расти началó с 50% и растет быстрее, чем мы ожидаем, например на 2% в минуту. Программирование на конфигах получим в итоге, ну а что делать?

Ну так в итоге, как поступать-то? В первую очередь надо понимать, что мониторинг нельзя настроить и забыть, за ним надо постоянно следить. И тогда и он будет постоянно следить за вашей системой. Во-вторых перед тем, как настраивать алерты, надо ответить себе на вопросы: что мы мониторим, зачем мы это мониторим и какое поведение является ненормальным для той сущности, которую мы мониторим. Чем больше ненормальных состояний вы опишите, тем легче будет настроить алерты.

Продолжение следует
(Впереди будет серия постов про #мониторинг)

Готовим распределенную систему

Зачастую инженеры живут в идеальном мире. В идеальном мире не случаются факапов, влияние человеческого фактора сведено к нулю, процессы соблюдаются и не происходит никаких нарушений. Посему часто инженеры, проектируя подобные системы, стелят соломку там, где им лучше видно, а не там, где может рвануть.

Давайте пройдемся по некоторым различиям реального мира и мира розовых поней

Заблуждение: сети надежны
Реальный мир: приложения пишутся без расчета на неприятности, происходящие на уровне сети. При сетевых сбоях приложения продолжают слать и слать запросы в никуда, не умея остановиться и обработать ошибку. А еще лучше — это заспамить паниками весь эррор лог. Или тупо свалиться. Ну это ладно, с высокой хрупкостью еще как-то можно жить и работать. А когда сеть поднялась, то ваша приложенька может зависнуть, не умея переподключиться и требует ручного рестарта. Сеть давно в порядке, а оно все лежит и спамит, не обработав ни саму ошибку, ни ситуацию, когда ошибка устранена

Заблуждение: в сети нет задержки
Реальный мир: игнорирование сетевых задержек и вызванных ими потерь пакетов приводят к тому, что приложение может засрать всю полосу, что значительно увеличивает количество потерянных пакетов и потерю пропускной способности.

Заблуждение: ширина канала бесконечна
Реальный мир: она весьма ограничена и мало того, что ее используете вы сами, так еще и несколько десятков-сотен других приложений, которые тоже пользуются (сюрпрайз, мазафака) тем же самым каналом. Так что гигабит, заявленный провом, доступен не только вашему приложению

Заблуждение: сеть безопасна
Реальный мир: есть огромное количество всяких темных личностей и автоматических программ, желающих присосаться к вашему трафику. Не доверяйте никому. Абсолютной защиты нет. Если вы пересылаете критичные данные по сети, то не надейтесь, что SSL/TLS спасет вас от утечки.

Заблуждение: топология сети не меняется
Реальный мир: меняется, очень часто и очень часто никто не будет оповещать вас об этом. И если вчера удаленная система пинговалась за пару миллисекунд, а сегодня пинг вдруг 200, то хорошо бы ваша приложенька могла это переварить. Если вам критична скорость доступа к удаленным ресурсам, то при разработке всегда держите этот факт в голове

Ваша инфраструктура — говно

И моя говно. 95% систем, обслуживающих трафик, говно. Вероятно, не говно делают всякие крупные компании, но и они сначала делали говно, а сейчас аккумулируют опыт, выстраданный десятилетиями. Ну или делают сразу хорошо за счет опыта приглашенных рокстарз. И то это очень сомнительно, потому что никто не знает, как могут измениться условия завтра. Признак профессионала — это готовность встретить любые проблемы, а не идеальная система в существующих условиях.

Не надо бояться делать говно, надо бояться ничего не делать. Лучше сделать говно и превращать его постепенно в конфетку, чем сделать очень круто, но никогда

Кто оценивает? Кто судьи? Кому вы даете право оценки качества системы, которую вы обслуживаете? Объективные критерии — это показатели мониторингов, error rate и количество жалоб от ваших пользователей. Мнение даже самых крутых специалистов может быть ошибочным, если они недостаточно погружены в вашу предметную область и в вашу конкретную систему

Ваша система обслуживает трафик. Она это уже делает, здесь и сейчас. Всегда надо помнить о том, что вы решаете, в первую очередь, бизнес-задачу. Любые улучшения, исправления и оценки следует делать, ориентируясь на бизнес-метрики. Если вы хотите сделать все по красоте, но при этом положите систему в даунтайм на пару суток или ухудшите пользовательский опыт, то это неверный путь

Вы же как-то справляетесь хоть и чувствуете что не везде. Вот это чувство, что "не везде", оно очень важное. Оно дает понимание чему стоит учиться и на что стоит обращать более пристальное внимание. Никто не стал профессионалом сразу, никто не построил сходу идеальную инфраструктуру. Итеративный путь развития оптимален.

Улучшайте постепенно, не стоит хвататься за все сразу. Первым делом надо понять, где могут быть самые болевые точки и застраховать эти места. Затем следует идти путем постепенных улучшений

Составьте план и двигайтесь по нему. Рисуйте план большими мазками и постепенно "прорисовывайте" детали. Хорошо работает метод прогрессивного джипега, описанный Лебедевым

Важно. Не забывайте про техдолг. Как разгребать его, так и фиксировать в нем все, что нужно сделать

#полезняшки

Буду брать какую-нибудь одну полезную хрень, которая как-то может облегчить жизнь, и писать про нее поподробнее

Начнем с самого большого и очевидного, но, оказывается, есть люди, которые про это не знают. AWS (Amazon Web Services) предлагает для бесплатного использования доступ к некоторой части своих ресурсов и сервисов. Очень хорошая возможность для поиграться с Амазоном, проверить гипотезу для своего проекта, запустить проект в свободное плавание. Ну а также пощупать всякие хайповые штуки и понять, как оно ведет себя в облаках.

Доступ предлагается в нескольких вариантах: бесплатно навсегда, бесплатно с ограничением по времени (12 месяцев) и пробный доступ

Из самого вкусного — это, конечно, EC2. Виртуалка уровня t2.micro на 750 часов в месяц. С линуксом или с виндой(!). До кучи туда же 5 Гб S3 и RDS на теже 750 часов. Вполне можно запустить проектик и посмотреть, жизнеспособно оно вообще или нет.

Для регистрации аккаунта требуется добавить карту. Есть и ложка дегтя. Ценообразование Амазона очень непрозрачное и можно налететь на то, что после бесплатного периода вы вроде как все отрубите, но Амазон продолжит снимать с вас денежку. И вы хрен найдете, что и где там у вас осталось включено. Вот чувак попал на подобную историю, советую почитать

На странице описания сервисов уровня Free Tier есть описание всех продуктов и фильтры, дабы не читать все подряд. Там их реально очень много.

https://aws.amazon.com/ru/free/

Продолжим про проектирование

Предлагаю задуматься вот о каком моменте: 3rd-party API.

О да, интеграции, мы всех их любим и все их используем. Это удобно, относительно надежно, избавляет от некоторого количества ручного труда и заставляет положиться на сознательность и разумность инженеров, которых вы никогда не видели.

Мониторинги, логи, запросы к онлайн-картам, отправке почты и смс, да тысячи их! В любом хоть сколь-нибудь большом проекте всегда есть десятки, а то и сотни интеграций со сторонними сервисами, которым мы делегируем часть нужного нам функционала.

Но наше приложение должно уметь работать с подобным подходом и просто fetch('https://remote.api/call/method') — это путь, который приведет к боли. Рано или поздно удаленная система упадет

Заранее подготовьтесь к ошибке
Корректно обрабатывайте отказы удаленной системы. Ваш проект должен уметь пережить это и не рухнуть, оставив пользователя с невнятной ошибкой. Застрахуйтесь, подстелите соломку. Хотя, в целом, это такой капитанский совет и вы должны всегда быть готовы к фейлу. Вот мой пример выше с fetch — это полное и тотальное отсутствие соломки. Но люди почему-то всегда верят удаленным системам больше, чем своим

И всегда имейте "План Б"
Я говорю сейчас про такую штуку, как graceful degradation. Точнее про ту ее часть, которая относится к взаимодействию с удаленными системами. Оставьте юзеру какую-то возможность продолжить взаимодействие с вашим приложением. Покажите ему что-нибудь из кэша, извинитесь, что прямо сейчас вы не можете удовлетворить его запрос, но покажите, что заботитесь о нем и не оставляете его наедине с его бедой. Помните как хром заботливо дает вам поиграть в динозаврика, когда нет соединения с Интернетом? Вот это как раз из этой серии и это очень хорошая практика

Be a manager

Руководитель обязан принимать решения не обладая должным ситуативным опытом, не имея полных данных и с высокой ценой ошибки

Можно делегировать часть ответственности, но нельзя делегировать ее всю, иначе зачем ты нужен как руководитель? Прослойки между людьми в цепочке, которые гоняют слова туда-сюда стремительно теряют ценность в продуктовых компаниях, но опять обретают ее в энтерпрайзе. Ну точнее они думают, что обретают.

Нанимать людей умнее себя — это как раз про это. Делегировать выполнение задач, делегировать ответственность за выполнение задач и собирать ответственность за результат в своих руках. Верить людям страшно, очень хочется сделать все самому. Страшно потому, что ответственность-то все равно твоя. За них, за себя, за свой кусок продукта и за того парня еще

Руководитель должен обладать видением (как же тупо пеерводится слово Vision на русский😁) как продукта в целом, так и своего места в нем. Я всю жизнь в инфраструктуре. Когда я научился рассматривать инфраструктуру как отдельный продукт внутри компании, жить стало гораздо легче.

Применение продуктового подхода в управлении инфраструктурой — хорошая, интересная и разноплановая задача, кстати

Продолжим про #полезняшки и про халяву от мажорных облачных провайдеров. Сегодня у нас на очереди Azure, продукт от Microsoft.

Там вы все также можете найти себе ресурсов на поиграться, как специфичных для этого конкретного сервиса, так и общих для всех (теже виртуалочки, ага)

В принципе, в Azure интересные решения для DevOps-овых всяческих штук и вообще любопытно посмотреть на то, что предлагает Microsoft сейчас притом, что они вошли на этот рынок последними, после гугла и амазона. (Ну по совести говоря, GCP и Azure стартовали почти вместе, у них разница полгода чтоли)

Итак, Эйжур дает нам 25+ своих сервисов в лимитированное использование навсегда, 12 месяцев использования на свои популярные сервисы (тоже в ограниченном использовании конечно) и 200 баксов на "полазить" по всему спектру предложений

Из виртуалок можно создать машинку на линуксе или винде. Azure DevOps (с безлимитными приватными git-репами кстати) и пайплайны (с безлимитным временем для опенсорса на линуксе, винде или (!)макоси), 5Gb БД от MS — Cosmos DB. Также есть реализация облачного Kubernetes от мелкомягких

Любопытный факт: Microsoft на данный момент — крупнейший контрибьютор в мире в опенсорс 🙂 Не говоря уж о том, что им принадлежит Github. Вот так за какой-то десяток лет в мире полностью поменялась картинка.

Полный список халявы: https://azure.microsoft.com/ru-ru/free/

А если удаленная система стала тупить?

Продолжим говорить про проектирование.
Частенько бывает, что ваше 3rd-party API начало тупить, что ж поделать и к этому, безусловно, тоже надо быть готовым. Основной месседж тут в том, чтобы этот факт не замедлял вашу собственную систему.

Всегда ставьте жесткие таймауты на удаленный вызов.
На любой удаленный вызов. Даже если это вызов к вашей собственной БД, которая в одном хопе от клиента. На той стороне может произойти все, что угодно и повисшие коннекты существенно замедлят или убьют ваше приложение.

Повторы на таймаутах
Удаленные системы и сети ненадежны и повторные попытки добиться от них результата повышают стабильность вашей собственной системы. Постарайтесь использовать какой-то более умный механизм повторных обращений к удаленной системе (об этом чуть дальше). Паузы между вашими ретраями могут дать продышаться удаленной системе, которая на данный момент, возможно, находится под серьезной нагрузкой. Обратная сторона повторных попыток соединения это идемпотентность

Используйте Circuit Breaker
Прекрасный паттерн, широко применяющийся в микросервисных архитектурах. Если ваш фреймворк поддерживает его (а, скорее всего, он поддерживает), то не стесняйтесь брать его в работу. Если нет, то обязательно реализуйте поддержку этого механизма

Не рассматривайте таймауты как ошибки
Таймаут удаленной системы — это не ошибка, а неопределенный сценарий поведения и обрабатывать его стоит именно как неопределенный сценарий. Вы должны явно определить в своем приложении механизм, который рано или поздно приведет системы в синхронное состояние при появлении неопределенного сценария

Не задействуйте вызовы удаленных систем в транзакциях
Исходя из написанного выше, вызов удаленной системы нестабилен по определению и поэтому выносите их из любых транзакционных действий. Обработайте транзакцию в стороне, выдав ей уже полученные от взаимодействия с удаленной системой данные .

Думайте о размерах ваших батчей
Вполне логично реализовывать пакетный режим (batch scenarios) при большом количестве удаленных вызовов. Разумно передавать и получать данные большими кусками и уменьшать расходы на обслуживание коннекта и передачи данных. Но помните, что большие батчи будут более нестабильными и тяжелыми для обработки, а слишком маленькие увеличат ваши расходы, которые вы пытаетесь сократить. К сожалению, однозначного ответа здесь нет. Оптимизируйте размер батча под ваш конкретный слцчай, пытаясь найти баланс между производительностью и устойчивостью к ошибкам

Эта неделька выдалась непростой. Подготовка к курсам в ОТУСе, первое демо-занятие и упавший продакшен сбили мой график выхода постов. Но усилием воли график возвращен на круги своя, идем дальше по плану.
Следующий пост в пятницу

Проектирование системы с удаленным доступом

Про использование удаленных систем в своих приложениях поговорили, теперь пришло время поговорить про проектирование такой системы, которая подразумевает использование себя в удаленном режиме. Проще говоря, предоставляет некий API с доступом через сеть. Несколько правил, которые облегчат жизнь вашим пользователям.

Вызовы API должны быть идемпотентными
Помните, мы говорили об этом раньше? Это обратная сторона использования ретраев. Пользователи могут использовать ретраи только в том случае, если уверены, что их использование безопасно. Поэтому каждый идентичный вызов должен приводить к идентичному результату и не иметь сайд-эффектов

Определите время отклика и гарантированную пропускную способность в SLA и следуйте ему при написании кода
Вообще круто, если у вас вообще был бы SLA, это дисциплинирует. Имея обязательства перед пользователями, вы пишите более устойчивый к ошибкам код. И ваши SRE-инженеры, определяя со своей стороны SLO и следуя им в повседневной работе, тоже могут полагаться на ваш код как на источник истины, а не источник проблем. Помните о том, что системы нестабильны и старайтесь сделать сообщения о проблемах в сети максимально информативными

Определить и лимитируйте размер пакетных вызовов (Batch API)
Вы не должны положить свою систему огромными батчами, которые, вероятно, захотят присылать ваши юзеры с хорошим железом на своей стороне. Жестко регламентируйте максимальный размер и частоту пакетных запросов и не забудьте написать об этих ограничениях в документации

Думайте об Observability в контексте всей вашей системы
Думайте об этом в первую очередь. Термин "Observability" означает, в том числе, возможность получить информацию о состоянии вашей системы без погружения в ее внутренности. Понимайте метрики, которые вы собираете, используйте правильные инструменты для сбора и анализа метрик, публикуйте события, происходящие в вашей системе, отдельным потоком. Мы про это еще поговорим в контексте постов про #мониторинг

Понимайте свои метрики

Зачастую собираемые метрики собираются потому что "надо", а не потому, что они отражают реальное положение вещей в вашей системе. Результатом являются красивые дашборды, которые можно распахнуть на весь монитор и там будет такая красота, которую не стыдно и начальству показать

Это все буллшит.
#мониторинг, являясь частью Observability, служит для понимания того, что происходит в вашей системе. И на дашборды не надо смотреть, показателем хорошего мониторинга является проактивность.

Начните понимать свои метрики прямо сейчас. Постройте дашборд с 4 золотыми сигналами, это уже даст вам огромный шаг вперед по пониманию текущего состояния вашей системы

Проанализируйте ключевые показатели для ваших сервисов и постройте дашборды, на которых вы будете видеть их состояние.

Избавьтесь от всех метрик, которые зашумляют ваше сознание и снижают уровень понимания системы, но не несут практической пользы.

Google Cloud

Продолжаем наши #полезняшки

Конечно же нельзя обойти вниманием и последнего игрока "большой тройки" на рынке облачных решений, а именно "корпорацию добра" — Google.

Гугловцы также предоставляют халявные плюшки в своей облачной платформе, а еще у них самый лучший и стабильный kubernetes (что неудивительно😁)

Милая деталька: в отличии от остальных, у гугла нет странички с описанием free tier на русском языке

Итак, гугл предлагает нам все примерно тоже самое: микроинстанс, доступ к БД, S3 и лямбды, а также интересная фича: облачная IDE

А еще они не берут денег за Control Plane кубернетеса в одной зоне, то есть чардж фактически только за вычислительные ресурсы. k8s я сам у них юзал, все очень хорошо.

Полный список халявы здесь
Обещают, что обозначенные ресурсы предоставляются бесплатно в рамках обозначенных лимитов. Срок использования неограничен, но это может быть изменено.

А еще они дают 300$ на "поиграться" новым пользователям. Вот здесь все описано подробно