За мою карьеру у меня выработались определённые мнения. Некоторые из них оставили особенно глубокий след, подкреплённый годами опыта. Я попытался сформулировать, что же у них есть общего. Общее заключается в мысли о том, что единственное, что важно — это код в продакшене. Обкатка не важна, код на твоём ноутбуке не важен, QA не важен, важен только продакшен. Всё остальное — это технический долг.
Такая точка зрения, вероятно, возникла из-за долгих годов работы между отделами эксплуатации и разработки продуктов. Я уверен, что эти отделы должны стремиться к оптимизации, позволяющей как можно скорее вывести код в продакшен, а также реагировать на инциденты в продакшене.
Эта мысль, а также все связанные с ней подразумеваемые действия, может показаться контринтуитивной или спорной, поэтому я хочу раскрыть её немного глубже. Ниже представлен перечень практик и принципов, которые я считаю правильными, исходя из моего мнения о том, что единственное, что важно — это код в продакшене.
1. Эксплуатировать свой код должны инженеры.
Разработчики — это главные специалисты по коду, который они пишут, и они должны отвечать за его эксплуатацию в продакшене. В данном контексте под «эксплуатацией» подразумевается деплой, инструментирование и мониторинг кода, а также помощь в разрешении инцидентов, связанных с этим кодом или влияющих на него. Ответственность за эксплуатацию кода стимулирует — она поощряет разработчиков писать поддающийся наблюдению и простой в отладке код, а также связывает их с тем, что на самом деле важно заказчику. Она стимулирует их интересоваться тем, как их код ведёт себя в продакшене. Важно, чтобы инженеры обслуживали код по вызову, это создаёт цикл положительной обратной связи и позволяет проще понять, окупаются ли их попытки писать готовый к продакшену код. Я слышал, что кто-то жалуется на перспективу обслуживания по вызову, поэтому задам только один вопрос: если код не будете обслуживать вы, то кто будет это делать?
Если вы ещё не обслуживаете свой код по вызову, но хотите это делать и можете повлиять на данное решение, то можно поступить следующим образом. Настроить графики PagerDuty (или подобного ему сервиса) для каждой группы инженеров, отвечающих за конкретные службы или части кода. Качественный график содержит 6–8 инженеров. Существует множество вариаций, но обычно используются недельные смены, когда ты неделю запасной на вызове и неделю основной. Настройка алертов — это отдельная тема, которая, вероятно, заслуживает целого поста, но в общем здесь стоит сосредоточиться на том, что влияет на заказчиков (см. Symptom-based alerting); помните, что в конечном итоге за реакцию на алерты отвечаете вы, так что вы можете их изменять.
Рекомендую посмотреть два доклада, касающиеся темы настройки алертов: Лиз Фонг-Джонс говорит о SLO в Cultivating Production Excellence, а Адитья Мукерджи обсуждает техники управления алертами в Warning: This Talk Contains Content Known to the State of California to Reduce Alert Fatigue.
2. Покупка почти всегда лучше создания
Если можно избежать создания чего-то, то это стоит сделать. Код — самый дорогой способ решения задачи, не касающейся основной сферы вашего бизнеса. Для большинства мелких или средних компаний существуют оперсорсные или лучше того — хостинговые решения, решающие широкий спектр стандартных задач. Я имею в виду такие вещи, как git-репозиториев (Github, Gitlab, Bitbucket, etc), инструменты для наблюдаемости (observability) систем (Honeycomb, Lightstep и т.п.), облачные базы данных (Amazon RDS, Confluent Kafka, и т.п.), системы алертов (PagerDuty, OpsGenie и т.п.), а также целую кучу других стандартных технологий. Это относится и к инфраструктуре — если возможно, не разворачивайте собственные кластеры Kubernetes (примечание: а вам вообще нужен Kubernetes?), не разворачивайте собственные балансировщики нагрузки, если можно использовать Amazon ELB или ALB.
К сожалению, синдром неприятия чужой разработки очень распространён и некоторые компании очень сильно на этом обжигаются. Я видел коллективы, тратящие время и деньги на повторное изобретение компонентов при наличии на рынке более качественных и проверенных опытом альтернатив. Те же самые коллективы почти всегда тратят потом годы на борьбу с накопившимся в результате техническим долгом. Если вы находитесь в такой команде, и у вас есть желание и возможность влиять на изменения, то начинайте по одному откатывать подобные решения. Перенесите свои базы данных в облако, проведите миграцию системы feature flagging в SaaS-инструмент (например, в LaunchDarkly). Продолжайте процесс, пока единственным поддерживаемым вами ПО не станет ПО, обеспечивающее выгоду заказчикам. Вы сильно выиграете от этого.
3. Упростите процесс деплоев
Деплои должны быть частым и скучным процессом. Инженеры должны иметь возможность выполнять деплои с минимальным ручным вмешательством. Успешность деплоя должно быть легко увидеть. (Для этого код нужно дополнить наблюдаемостью, о чём я говорил выше). Кроме того, если что-то пойдёт не так, то деплой должен легко откатываться назад. Частые деплои подразумевают небольшие объёмы, а мелкие деплои обычно выполнять проще, быстрее и безопаснее.
Во многих командах существуют графики запрета деплоев (их могут называть code freeze) или применяются политики деплоев типа «Никаких деплоев по пятницам». Из-за таких периодов простоя могут накапливаться изменения, что увеличивает риск аварий.
Если вы работаете в команде, боящейся деплоев, то потратьте часть своего времени разработки на усовершенствование конвейера деплоев, чтобы устранить этот страх. В моём предыдущем коллективе мы смогли снизить время деплоев с трёх часов до 30 минут, что значительно повысило уверенность команды в процессе деплоев. Естественным побочным эффектом этого стало то, что разработчики стали выполнять деплои намного чаще и перестали ждать накапливания изменений, достаточных для создания «релиза» (это слово было у нас синонимом деплоя).
Большое внимание в последнее время привлекла книга Accelerate. Рекомендую прочитать её, если вы ещё этого не сделали. Её авторы также публикуют отчёты State of DevOps, в которых полно тщательно исследованной информации о состоянии различных компаний отрасли. Неудивительно, что две из четырёх ключевых метрик, на которые делается упор в книге, непосредственно связаны с нашей темой (Deploy Frequency, Change Lead Time). Деплои — это пульс вашей компании.
4. Доверяйте людям, которые ближе всего к практической работе
Лучше всего понимают систему те, кто с ней работает. Это относится к любым частям социально-технических систем, в которых все мы участвуем. В случае программных систем уровень рисков эксплуатации лучше всего понимают инженеры, ежедневно выполняющие деплои и обслуживающие по вызову наиболее критичные службы. Существует печальная тенденция — менеджеры обычно переоценивают степень прогресса команд в некоторых переходных процессах, например, при переходе в облако, DevOps, и т.д. Чем выше по цепочке руководства, тем больше эта погрешность оценок. Инженеры, которые выполняют деплои и которым звонят, когда что-то ломается, знают, где закопаны все скелеты и во что нужно вкладывать больше труда. Поэтому они должны быть основными заинтересованными лицами, ответственными за расставление приоритетов технической работы.
Ещё одно проявление этого принципа относится к командам, работающим с платформой или оказывающим технические услуги. Если вы отвечаете за создание некоего общего компонента, используемого в вашей организации (например, системы обмена сообщениями, CI/CD-инфраструктуры, общих библиотек или сервисов) то вас ждёт неприятное открытие: люди, пользующиеся результатом вашей работы, во многих случаях знают о нём больше, чем вы. Они косвенно понимают, как она обслуживает потребителей и знают, какие препятствия и проблемы нужно преодолеть, чтобы заставить систему работать. Прислушивайтесь к ним, чтобы понять, как улучшить UX ваших сервисов и инструментов.
5. Меры QA снижают качество
Во многих командах есть этап ручного QA, выполняемый перед деплоями. Предполагаю, что идея в том, что кто-то должен проводить автоматизированные или ручные тесты для проверки готовности набора изменений к релизу. Выглядит эта идея успокаивающе — у тебя есть человек (или коллектив) «проверяющий» релиз перед выпуском, однако она становится жертвой множества ложных допущений и создаёт расхождения, приносящие больше вреда, чем пользы.
Во-первых, если перед выпуском деплоя необходима какая-то ручная работа, это создаёт помехи — если вы деплоите легко и часто выпускаете небольшие изменения, то никакой отдел QA не сможет справиться с тестированием каждого деплоя и неизбежно будет мешать деплоить. Это плохо. Если у вас есть ручные тесты, автоматизируйте их и встройте в свой CI-конвейер (если они действительно имеют ценность).
Во-вторых, выполняющим QA отделам часто не хватает контекста и времени. В результате они могут начать тестировать «воздействие» вместо «задач». Например, я видел примеры того, как отделы QA тратят время на тестирование того, что при совершении действий с UI что-то происходит в базе данных. Что случится, когда разработчик проведёт рефакторинг этого компонента UI и изменит лежащую в его основе модель данных? Функциональность продолжит работать, однако тесты поломаются. Поскольку в это втянуты два отдела, для исправления потребуется координирование и время. Ещё я видел, как отделы QA препятствовали деплоям из-за непрохождения тестов после добавления в слой CDN кэширования — TTL в 5 секунд ленты новостей может быть даже незаметен пользователю, но способен испортить тесты QA, вызывая необязательные конфликты между разработчиками и инженерами QA.
К счастью, эту проблему решить легко. Вместо специального отдела QA, работающего над ручными и автоматизированными контрольными тестами, выполняемыми в выдуманной QA-среде, нужно направить усилия этой команды на постоянное тестирование в продакшене. Вместо того, чтобы быть шлюзом для деплоев, отдел QA может непрерывно проверять работу продакшена. Кроме того, отделы QA хорошо подходят для ведения проектов хаос-инжиниринга, при которых в продакшен намеренно инъектируются сбои. Инженеры QA могут также работать над повышением надёжности CI/CD-конвейера, чтобы деплои больше не превращались в кошмар.
6. Скучная технология — это отлично.
По возможности всегда стремитесь к скучным технологиям (см. пост Дэна Маккинли). Системы по сути своей непредсказуемы, и когда всё начнёт разваливаться, всегда нужно иметь страховку в виде обширных накопленных знаний. Кроме того, существуют обязательные рутинные операции (деплои, миграции баз данных и т.д.), поэтому для подобных вещей удобно применять широко используемый и хорошо протестированный инструментарий. Когда я думаю об этом принципе, то чаще всего вспоминаю базы данных. У MySQL есть множество хитрых особенностей, но при этом она широко используется и в большинстве случаев нужно стоит всё-таки придерживаться её.
Очень немногие организации имеют достаточно ресурсов для отладки уникальных проблем. Нам не нужны уникальные проблемы, особенно при выполнении рутинных операций — сохранении байтов на диск, выборе нового лидера в кластере, сборке мусора, запрашивании временных данных и т.п. Возникновение уникальных проблем убьёт мелкую и даже среднюю команду. Она вытянет из вас всю вашу энергию творчества, которую лучше использовать для создания выгоды заказчиков, желающих платить деньги за ваше ПО. Тратьте свои жетоны инноваций с умом!
При использовании скучной технологии можно положиться на большое сообщество её пользователей. Можете как хотите ругаться, но существует очень мало проблем PHP, с которыми до вас не столкнулся кто-то ещё. Сегодня это, вероятно, справедливо для достаточно широко используемых версий Ruby on Rails. Я часто говорю, что стремлюсь находиться в третьей волне освоения технологий. Первая волна — это организация, находящаяся на переднем крае прогресса. Вторая волна — это люди, готовые на определённый риск. Пропустите вперёд эти две группы, пусть они столкнутся со всеми крупными проблемами, а потом ступайте сами, получая выгоду от всего их наработанного тяжким трудом опыта.
7. Простота всегда выигрывает
Здесь мало что можно сказать, но мы все ведь пишем YAML и JSON вместо XML, а пользуемся HTTP вместо CORBA, RMI, DCOM, XPCOM и т.д. Правда? Аналогично этому, я бы лучше отлаживал проблемы в LAMP-стеке вместо архитектуры микросервисов.
Краткое примечание о микросервисах: как и многие технологические тренды, они позиционируются как панацея. Не поймите меня превратно: при правильном проектировании микросервисы способны решать некоторые специфические проблемы, как и многие решения сложных проблем, требуя при этом определённых компромиссов. Если вы хотите двигаться в этом направлении, то у меня есть мнение о том, как это следует делать, но я также считаю, что этого стоит избегать как можно дольше.
8. Среды вне продакшена имеют убывающие доходы
Можно было бы использовать и более прямой заголовок — «Среды вне продакшена — это чушь». Среды типа обкатки (staging) или препродакшена — это абсолютная ложь. В начале проекта они имеют небольшой смысл, но когда он начинает расти, изменения происходят чаще и вы начинаете ощущать инерцию. Кроме того, среды вне продакшена по определению не получают трафика, из-за чего фундаментально отличаются. Количество трудозатрат на поддержку сред вне продакшена нарастает очень быстро. Вам никогда не удастся отдавать приоритету работе вне прода, потому что заказчики не касаются его напрямую. Потом вам придётся выкраивать ресурсы на работу этой среды, собранной из палок и изоленты, чтобы можно было тестировать в ней изменения, лгать себе, притворяясь, что она хотя бы чем-то похожа на продакшен.
9. Всё всегда ломается
Избегать неудач невозможно, и даже нежелательно. Смиритесь с тем, что сбои неизбежны, и сосредоточьтесь на том, как на них реагировать. Это означает, что потребуются инвестиции в постоянно совершенствующийся процесс реагирования на инциденты. Не существует готовых систем, подходящих для любой компании или коллектива, но вы должны иметь хорошее представление о том, что делать, когда что-то начинает ломаться, и иметь налаженные механизмы, позволяющие учиться на этих ситуациях и совершенствовать ваши процессы. Вложитесь в анализ инцидентов. Это огромная область со множеством ценных инструментов и ресурсов для максимизации эффективности инвестиций при возникновении инцидентов (или когда они не возникают!).
В этой области может быть полезным хаос-инжиниринг. Инъекции сбоев в продакшен могут повысить уверенность в том, как реагировать на неожиданное поведение системы. Особенно эффективным способом тренировки инженеров по различных ситуациям сбоев могут быть Game Days.
Заключение
Многие из точек зрения, перечисленные в этом посте, кажутся как минимум контринтуитивными, а то и спорными, однако я всё-таки уверен в их истинности. Это не значит, что меня не переубедить, но это маловероятно. Если вы абсолютно согласны или не согласны, то пишите мне в Твиттер. Мне было бы очень любопытно послушать о вашем опыте.
На правах рекламы
Закажите и сразу начинайте работать! Создание VDS любой конфигурации в течение минуты, создайте свою конфигурацию в пару кликов.
Автор: Mikhail
