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

Такой кажущийся очевидным вопрос, любой специалист тут же готов на него ответить. Но, что характерно, отвечают все по-разному. Для кого-то это некая "система", продукт конкретного вендора: 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$ на "поиграться" новым пользователям. Вот здесь все описано подробно

Возвращаясь в реальность

Собеседовал недавно человека на позицию девопса. Ищу человека себе в команду для довольно приземленных задач. И вот человек мне говорит:
— Я yaml-ы писать не хочу, это вот совсем не мое. Я вообще офигенный разработчик и хочу писать на расте для linux kernel. Или какие-нибудь крутые инфраструктурные штуки делать. Но я особо не умею и поэтому ищу того, кто меня научит

Я, честно говоря, сначала охуел прилично. А потом спрашиваю: А в чем твоя ценность для бизнеса, как инженера? Что ты вообще можешь дать, какое value принести в команду и процесс?
И он начал мне рассказывать какие крутые проекты он делал, какие прям вот сильные вещи писал.
Не понял, в общем, вопроса. Окей, продолжили. Работает он сейчас в Mail.Ru. Говорю. ну вот Мейл делает tarantool, крутой проект же. К тому же в опенсорсе. Что ты к ним в команду не попросишься?
— Не, отвечает, тарантул мне не нравится. Код там говно, lua еще эта сраная, и вообще, еще один key-value не нужен, есть клевый etcd, там raft, алгоритмы консенсуса и все такое, это я люблю.
(про использование тарантула как application server-а с офигенно быстрым kv на борту он, видимо, не подумал)
— Ну так сделай его клевым, — говоря ему я, — почему бы и нет?
— А я на сях не умею! Да и не хочу. Вот раст круто, я хочу писать на расте для Linux kernel
— Ну хорошо. Пусть так. А ты пробовал вообще что-нибудь для ядра писать? Вон доков в сети навалом (мне было интересно его мнение про дизайн Kernel API)
— Не, я не пробовал ничего. Не могу придумать, что написать. Все уже написано🤷‍♂️

Хорошее интервью получилось.

То есть человек реально не понимает, каков в реальности процесс зарабатывания денег ему на немаленькую, между прочим, зарплату. И зачем мы вообще тут все собрались.
Я бы мог ему найти задач и под его потребности (не, для kernel мы не пишем ничего, но для крутого автоматизатора, например, я поле непаханное работы могу найти и не ямлы писать, а реальный код для инфраструктурных проектов), если бы он понимал, что такое бизнес и какова роль этого бизнеса в том, что он делает. И что я делаю. И что делает каждый участник команды.
И не существует интересных задач. Все задачи одинаково интересны и неинтересны в тоже время. У самой задачи вообще нет такого свойства, по-моему. Интересной или нет, ее делает исполнитель, и вот именно в этом моменте раскрывается его талант инженера

Infrastructure as Software

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

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

Так появились agile-методологии, devops-практики, тут пропустим большой пласт истории, каждый желающий может найти по этой теме сотни статей на том же хабре и придем к тому, что мы имеем сейчас: у нас есть кубернетес, эдакий новый стандарт в индустрии, умеющий вообще все, что связано с запуском любых приложений. Имеет в основе своей декларативный формат описания своих сущностей. И их у него там не одна или две, а прям дохера, густо сплетенных между собой. И помимо базовых встроенных примитивов кубернетеса есть возможность писать свои, так называемые Custom Resource Definitions, что уносит количество примитивов прямо-таки в облака. Для тех же операторов кубера уже есть цельный отдельный "хаб". В итоге мы имеем пачку yaml-ов, огромное количество неочевидных связей между ними и какую-то логику их применения. Круто, можем положить это в гит и иметь версионирование, git blame и все вот это, что мы так любим.

Дальше у нас есть некий нижележащий слой условного железа, который в современной cloud-native среде превращается все равно в теже выделяемые провайдером ресурсы, которые надо бы как-то сначала сконфигурировать. Ну и плюсом у вас, например, не только кубернетес, а еще и какие-то ресурсы рядышком. Нужен Configuration Manager, который автоматом развернет и сконфигурирует приложения, да и тот же кубер например. Берем Ansible и получаем еще один набор ямликов, который описывает первичную конфигурацию всего нашего хозяйства. Ну и логику их применения конечно. Ах да, плюсом ансибл не знает ничего про состояние и в этом моменте его декларативность сыплется и нам уже нужно добавлять какую-то императивную логику, дабы все не порушить к херам. Но да, опять все положим в гит, потому как это все текстом описано удобненько

Но Ansible не может "заказать" ресурсы у провайдера, а может только работать уже с готовыми. А если вы оперируете сотнями инстансов VM у разных провайдеров (а VM, ну точнее Compute Node, например, все еще является базовым примитивом у облачного провайдера и никуда от них не деться), то человеческий фактор довольно быстро смачно даст вам под дых и превратит семейный субботний вечер в debugging hell. Нам на помощь приходит Terraform, приносит с собой свой собственный декларативный формат описания состояния, умеет получать информацию об этом состоянии прямо-таки вот из первых рук и вообще, очень хороший и удобный инструмент. Основную движущую силу которого, tf-файлы, также можно хранить в гите. Ну и иметь некую логику их применения.

И вот мы подошли к самому интересному. У нас есть гит как источник истины (Single Source of Truth), есть наша платформа, которая видоизменяется в соответствии с изменениями в нашем SSoT и есть инструменты, которые синхронизируют эти две сущности (GitOps, Infrastructure as Code и все такое). И вроде все кайфово и хорошо, но! Кто-то должен класть деньги в тумбочку. То есть эти ямлики в гит. И вот тут мы получаем развесистую пощечину и специальность "yaml-инженер". И я не шучу. Дело в том, что вот вся эта декларативная куча 💩 должна как-то управляться, а в силу декларативной природы, реализации логики в ней нет. А есть она в голове у инженера.

И люди начали задумываться о том, что управлять этим всем очень непросто и мы опять наворотили непомерно сложную махину в погоне за простотой. И хорошо бы наши декларативные описания и логику их применения не разносить по разным сторонам (гит и голова инженера), а таки стащить их в сторону гита и генерировать все автоматом, не занимаясь программированием на конфигах. А заодно понизить порог вхождения и повысить bus factor. А так как программированием все равно заняться придется, то и нечего выеживаться. Ну и в итоге мир стабилизировался. DevOps-ы садятся и пишут императивный код, генерирующий прекрасный декларативный мир, описывающий инфраструктуру. И получаем мы именно то, о чем написано в заголовке. Инфраструктуру как самостоятельное ПО. И сейчас оно довольно простое и даже выглядит решением проблемы. Как выглядел этим самым решением каждый шаг, пройденный инженерами и описанный в этом посте. Вангую, пройдет лет 5 и мы будем спорить об инфраструктурных фреймворках, которые под капотом будут управлять тысячами декларативно описанных сущностей, уже не поддающихся пониманию человеком.

Heroku

#полезняшки продолжает очередная платформа, позволяющая вам захостить свой пет-проджект без нанесения ущерба бюджету. "Большую тройку" с кучей сервисов мы уже разобрали, теперь поговорим про ребят попроще, но все равно довольно больших. Сегодня у нас на прицеле Heroku

Heroku — это PaaS, предлагающий вам доступ к небольшому, но очень полезному набору инструментов и также имеющий бесплатный тариф "на поиграться". Впрочем, начальные опции там тоже очень недорогие, если вы вдруг решите расти именно на Heroku

Итак, что мы получим на халяву?

До 1000 dynos, так в Heroku именуется их собственное решение для контейнеров, именно в них запускается ваше приложение. Будьте осторожны, контенйер будет погашен автоматически, если в течении 30 минут к приложению в нем не будет обращений. Имеет смысл периодически дергать ваше приложение какой-нибудь внешней пинговалкой (хоть с вашего домашнего компа, если он работает постоянно)

Managed Postgres c ограничением на 10К строк

Managed Redis (20Mb RAM и 20 коннектов)

Managed Kafka (7 дней хранения данных и 4 гигабайта)

И кучу аддонов на все случаи жизни

Также Heroku поддерживает так называемые Buildpacks — это инструменты для запуска приложений, написанных на различных ЯП, в рамках Heroku

Для управления вашим сетапом вне Web UI Heroku имеет удобную утилитку

Как видите, богатство выбора не такое как у "Большой тройки", но и пафоса поменьше :) Отличный выбор, чтобы покрутить своего пета

Чеклисты

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

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

Это очень хорошая и полезная практика. Если вам необходимо выполнить какой-то очень ответственный процесс, потратьте два часа и составьте чеклист, вставляйте туда самые очевидные пункты, в момент "Х" вы можете про них просто забыть.

Если у вас есть какие-то рутинные операции, которые, в силу их природы нельзя автоматизировать, составьте чеклист и спасете себя от замыливания взгляда. Да еще и мозг освободите для более полезной работы.

Чеклисты — это инструмент автоматизации в тех сферах, где нельзя воспользоваться программными средствами.

Воскресные развлечения. Обновляю систему с аптаймом в три с лишним года🤦‍♂️
Сервачок мой личный, как-то я подзабыл про него.
Заодно и проверим, насколько убунта переживет апдейт через два LTS-релиза. Буду обновлять до актуальной 20.04 LTS
UPD: пережила нормально :) Все сервисы запустились и работают. Были сложности с промежуточным обновлением до 18.04, а до 20.04 обновилась даже без ребута. Лайк👍
UPD2: Ну респект, кстати, диджитал-оушену. Больше 3 лет VM-ка у них проработала и ни единого разрыва, то бишь ребута. Мое уважение.

Разработка vs Эксплуатация

Начинал я вообще фронтендером :) Тогда это называлось HTML-верстальщик и писали мы на ванильном js, тогда даж жиквери еще не вышел на большую сцену и не перевернул мир. На дворе был 2003 год. Потом было много программирования, я писал на PHP, на перле, на сях, на джаваскрипте, на tcl даже и параллельно с этим изучал линуксы.

И в какой-то момент времени понял, что просто писать код мне неинтересно. Тогда (это где-то 2008 год) еще не было такого единения разработки и эксплуатации, devops только зарождался на западе и программисты просто коммитили свой код и тут же писали новый. Судьба уже написанного их волновала только тогда, когда код к ним возвращался с уже описанными багами. Я тогда много тусил с "большими ребятами", это badoo, яндекс и все вот эти чуваки, которые меняли правила игры в индустрии. И у них было много решений на уровне эксплуатации, которые меня прям поразили. Они придумывали что-то новое там, где, казалось, уже нельзя было ничего придумать. А потом кто-то привез концепции DevOps и все, мир для меня поменялся в сторону любви к инфраструктурным решениям.

Тот факт, что я довольно долго проработал программистом, помогал мне хорошо понимать как код, так и проблемы/потребности разработчиков, а довольно хорошее знание линукса и умение его приготовить позволяло мне строить эффективные системы.

В итоге я сформулировал для себя такой ответ. Мне субъективно интереснее эксплуатация потому что:

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

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

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

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

Возможность влиять на процессы across the company тоже очень драйвит. В матричной структуре компании инфра/девопс — это всегда сервисная горизонталь, которая взаимодействует со всеми продуктовыми командами и строить процесс деливери на этом уровне очень интересно.

Ну и челлендж, куда же без него :) Эксплуатация — это всегда сущность, которая только тратит деньги. Напрямую команда devops/sre не влияет на прибыль и поэтому я могу вносить свою лепту в revenue только двумя путями: уменьшать расходы и оптимизировать существующие процессы. Ну и следить за выполнением SLA конечно

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

"А я еще я немножечко шью" 😁

Ngrok

Продолжаем #полезняшки теперь уже не платформами, а инструментом. Сегодня у меня на карандаше отличная тулза https://ngrok.com/

Инструмент не нов и достаточно известен и я с удовольствием расскажу про него. Ngrok позволяет зашарить любое приложение с открытым портом в интернет буквально в одно действие. Запускаете приложеньку у себя на локалхосте, например веб-сервер на порту 8080. Запускаете ngrok и говорите ему, что у вас на порту 8080 висит приложенька. Он в ответ выдает вам адрес вида http://d52ccfa03be8.ngrok.io/ и вуаля! Ваше приложение доступно через интернет. Незаменимая штука, когда надо по-быстрому зашарить кому-нибудь приложение с локалхоста. Ну или вебхук повесить какой-нибудь.

Из коробки есть SSL. У софтины есть свой собственный веб-интерфейс, живущий на 127.0.0.1:4040

Можно поднять несколько видов туннелей: http, tcp и tls. Соответственно, можно и ssh затуннелировать вполне, например

На бесплатном тарифе вам доступны 1 процесс online, 4 туннеля и 40 коннектов в минуту. Можно, кстати, даже без регистрации, но тогда туннель умрет через 2 часа

Для любителей поковыряться ручками и параноиков есть опенсорсная альтернатива, написанная на node.js: https://localtunnel.github.io/www/ Можно захостить у себя и также пробрасывать туннели одним движением. И не платить ничего за полный функционал🙂

Увеличение на порядок

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

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

Поэтому на собеседованиях я стараюсь проверить как человек думает, а не насколько хорошая у него память