Примечание переводчика: статья о том, как простой жест — посадить разработчика рядом с инженером эксплуатации во время деплоя — запустил цепную реакцию перемен и привёл к настоящей DevOps-трансформации. Дальше слово автору.
Мое первое знакомство с DevOps было настолько будничным, что я даже не осознал всей его мощи. Позвольте мне поделиться, как случайное открытие переросло в осмысленную практику и почему тот момент стал для меня переломным.
Всё началось с довольно типичной для многих компаний схемы поставки ПО. Команда разработки писала код итеративно и инкрементально. Примерно раз в месяц они собирали «золотой» релиз и отдавали его команде эксплуатации.
Команда эксплуатации ставила софт на внутренний сервер — да, мы сами пользуемся своим продуктом. Убедившись, что всё стабильно работает в течение двух недель, они выкатывали версию клиентам.
Процесс был не без изъянов, но все к нему привыкли и работали на автомате, так что никто не торопился что-то менять. Понимание, что так дальше нельзя, пришло с первым настоящим DevOps-опытом.
Тот самый незапланированный опыт
Когда команда эксплуатации выкатывала новую версию, они всегда проверяли логи на предмет чего-нибудь интересного и неожиданного. Когда что-то находилось, быстрого ответа они получить не могли, поэто��у часто предпочитали просто откатиться назад.
Ситуация была до смешного абсурдной, ведь команда разработки сидела в паре метров от них, в соседней комнате. Поразительно, как обычная дверь превращает коллег в одном офисе в удалёнщиков.
Команда эксплуатации пилила запрос по официальным каналам, а в это время разработчики понятия не имели, что подкинули коллегам работы и стресса, потому что тикет до них ещё не добрался.
К счастью, один из инженеров эксплуатации поднял этот вопрос. В следующий раз, когда они запустили развёртывание, к ним подсадили разработчика — следить за логами. Решение незамысловатое, о котором особо и не задумаешься. Этим разработчиком был я. А моего коллегу-девопса для этой истории назовём, скажем, «Тони».
Совместные открытия помогают развиваться
Первый наш опыт совместной работы не казался чем-то прорывным. Когда в логах появлялось сообщение, которое удивляло Тони, оно удивляло и меня. Эти сообщения были одинаково непонятны как разработчику, так и девопс-инженеру.
Я прикидывал возможные причины, мы их обсуждали, и в итоге у нас с Тони рождалась гипотеза. Мы тут же её проверяли, пытаясь воспроизвести аналогичное сообщение в логах. А потом ломали голову: терпит ли время до фикса или лучше откатиться?
План свести людей из двух команд вместе был призван убрать задержки в общении, и это сработало. Но, как оказалось, были и побочные эффекты, которые в итоге принесли куда больше пользы.
Замыкаем круг: пусть боль вернется к источнику
Когда ты сам пишешь код, который генерирует логи, а потом тебе же приходится в них разбираться, ты замыкаешь «круг боли». Такие круги — лучший двигатель прогресса.
В большинстве компаний эти круги разорваны. То есть кто-то создаёт проблему (к примеру, разработчик, чей код спамит тысячами непонятных ошибок в минуту), а страдает от неё другой, например Тони, который пытается в этих логах что-то разобрать.
Есть два способа решить эту проблему:
Бюрократия: придумать кучу правил и процедур, чтобы боль не так сильно била и случалась пореже.
Замкнуть круг: сделать так, чтобы тому, кто создаёт проблему, от неё же и «прилетало».
Если меня бьёт током, когда я нажимаю кнопку, я очень скоро перестану её нажимать, даже если меня будут убеждать, что так надо для эксперимента.
Когда этот круг замкнулся на мне, до меня дошло: надо писать в логи меньше, чтобы не приходилось часами их листать и анализировать. Вместо того чтобы запоминать, какие сообщения можно игнорировать, потому что они и так постоянно вылазят, мы могли просто их отключить.
Наша идеальная (может, и недостижимая) цель была в том, чтобы логировать только то, что следует видеть человеку. А при необходимости можно было бы включить детальные логи. Тогда вместо бесконечной простыни текста у тебя был бы почти пустой экран. И когда там что-то появлялось, оно точно заслуживало внимания.
Потом мы придумали сделать сообщения в логах понятнее. Чтобы было сразу видно, у какого клиента или пользователя случилась ошибка и что вообще происходит вокруг (то есть дать контекст). Благодаря этому мы часто находили причину бага, даже не заглядывая в исходники, что кардинально сокра��ало время на дебаг.
Результатом нашим мытарств стали так называемые «Три F логирования» (нажмите, чтобы изучить подробнее).
«Три F» — ваш путь к идеальным логам
Просто возьмите самое частое событие из лога и решите, что с ним сделать:
Finesse (Доводи до ума)
Fix (Правь)
Filter (Фильтруй)
Давайте кратко рассмотрим каждый пункт.
Finesse (Доводи до ума)
Если от записи в логе мало толку, потому что в ней не хватает информации, её нужно довести до ума. Переделайте логирование так, чтобы в запись попадала полезная информация.
Я работал в компании, где было простое правило: если по одной записи в логе ты не можешь объяснить коллеге, в чём проблема, эта запись не оправдывает даже места, которое занимает на диске. Через полгода люди могли понять причину проблемы, даже не заглядывая в код, — настолько классно были составлены логи.
«Довести до ума» — это когда вместо «500 Internal Server Error» вы получаете: «Попытка подключиться к основной базе данных с веб-сервера 5 отвалилась по тайм-ауту через 30 секунд, когда пытались загрузить “Акции для пользователя” с ID 187 на строке 52 контроллера Promotions: 52 promotionQueries.GetPromotionsForUser(userId);». Короче говоря, абстракции — это хорошо, но не в сообщениях об ошибках.
Fix (Правь)
Когда у вас на руках есть чёткое и внятное сообщение об ошибке — пора её исправлять. Тут всё просто, но разработчики часто бегут впереди паровоза. Не переходите к исправлению, пока не закончили «доводку до ума» (finesse). Иначе тот двухчасовой квест, который помог вам докопаться до корня проблемы, придётся проходить заново, если текст ошибки останется прежним.
После исправления количество ошибок в логе должно резко снизиться (если баг был массовым) либо они должны исчезнуть совсем.
Кстати, «исправление» — это не только правка в коде. Это может быть, например, автоматизация решения через сценарий (runbook).
Filter (Фильтруй)
Давайте честно: некоторые ошибки бессмертны. По какой-то причине служба BITS иногда не стартует, но на работу это никак не влияет — если только вы не фанат асинхронной передачи файлов по хитрым протоколам (смеюсь).
Так что некоторые записи в логах нужно просто игнорировать. Волшебный способ, который изменит вашу жизнь: поблагодарите лог за работу и создайте правило, чтобы они больше не мозолили вам глаза.
Что дальше?
Если «Три F» не помогают, скорее всего, информация об ошибке просто попадает не туда. Допустим, в ops-инструменты падают ошибки, которые может исправить только сам пользователь. В таком случае нужно придумать, как передать это сообщение именно ему. Найдите способ автоматически доставлять информацию нужному человеку. Например, если на сайте есть битая ссылка на внешний ресурс, лучше вывести отчёт об этом редакторам контента, чем забивать ops-логи.
Идеальное завершение
Идеальным результатом применения «Трех F» стало бы полное отсутствие логов. Скорее всего, это недостижимая цель, но к ней надо стремиться. Продолжайте применять «Три F» к самым «шумным» записям в логах до тех пор, пока не наведёте в них полный порядок.
Позитивная спираль: деплои, которые приносят радость
Пока мы сидели вместе во время деплоев, до нас дошло: сам процесс просто ужасен. Мы создавали установочный файл, команда эксплуатации закидывала его на целевой сервер, дважды кликала и следовала подсказкам по настройке приложения.
Приходилось вручную вбивать конфиги в установщик, что было медленно и чревато ошибками. На улучшение этого процесса мы потратили непростительно много времени.
Честно говоря, мы «чинили» это всё по старинке: писали для каждой установки самопальные скрипты и т. п. Но это никак не облегчало жизнь, когда нужно было развёртывать ПО в разные окружения и на кучу prod-инстансов.
Зато я на себе испытал, что такое стресс от деплоя, когда нет стопроцентной уверенности в его успехе. Когда деплои — это лотерея, они бьют по репутации команды, подрывают доверие и лишают самостоятельности.
Провальные деплои — главная причина, почему компании начинают выкатывать изменения большими пачками. А большие пачки — главная причина провальных деплоев. Это ещё мягко называют «негативная спираль», и для того, чтобы выжить, её нужно срочно развернуть в обратную сторону.
И вот она, панацея
Конечно, просто посадить разработчика рядом с инженером эксплуатации на время деплоя — не значит решить все проблемы. Мы выросли с 6 до 30 разработчиков, пробовали новые идеи для продукта, меняли позиционирование и цены — и проблемы постоянно лезли из всех щелей. Постоянное улучшение как игра в «ударь крота»: только одного прибьёшь, тут же вылезает другой.
И всё же этот простой шаг — просто сидеть вместе, или, по-умному, «коллаборация», — запустил цепную реакцию полезных изменений.
Общие цели и общая боль
Когда ты сидишь с кем-то плечом к плечу и решаешь одну задачу, все эти барьеры между отделами испаряются. Вы просто пара парней, которые пытаются сделать так, чтобы всё заработало.
Вместо того чтобы спрашивать с разработчиков за количество фич, а с команды эксплуатации — за стабильность, у нас появилась общая цель: высокая скорость и стабильность поставки ПО.
Это устранило конфликт интересов и побудило нас делиться и решать проблемы совместно. Кстати, трюк прекрасно работает и при взаимодействии с другими отделами, например с безопасниками или финансистами.
Замыкаем круг боли
Проблема с логами стала очевидной, когда человеку, который их генерирует, пришлось самому с ними разбираться. Это отличный мотиватор для перемен.
Найти источник проблемы и замкнуть «круг боли» на его создателе — не наказание, а момент прозрения. Именно поэтому мы все должны пользоваться софтом, который пишем: сразу видно, какие именно проблемы мы подкидываем пользователям.
«Круги боли» — ключ к реальным улучшениям в поставке программного обеспечения.
Убираем рутину
Хорошие разработчики — мастера автоматизации. Когда они видят монотонную, повторяющуюся работу, их первый порыв — избавиться от неё.
Для команды эксплуатации пошаговый чек-лист деплоя был обычным делом. Они так к нему привыкли, что просто перестали его замечать.
Когда рутины стало меньше, ребята из эксплуатации явно повеселели — и это притом что некоторые острые углы по-прежнему сохранились.
Совершенствуем идеи
Готовые идеи появились не сразу. Их грубые очертания со временем отшлифовались и превратились в набор повторяемых и связанных между собой DevOps-привычек.
«Три F», принципы анализа инцидентов, стратегия алертинга и правила выбора метрик для мониторинга выросли в полноценные методики уже гораздо позже этой истории.
Я разработал подход к улучшению процесса поставки, который использовал эти идеи для восстановления доверия между разработчиками и бизнесом. Сократив негатив от неудачных деплоев и число багов, ускользнувших от внимания, мы вернули доверие к команде разработки, повысили её репутацию и расширили автономию.
Затем дополнили эти практики инструментами Octopus Deploy для автоматизации деплоев и ранбуков, а также платформой для наблюдаемости. В результате именно мы узнавали о проблемах первыми, а не наши пользователи. Когда что-то шло не так, это было легко починить, а новую версию можно было выкатить практически мгновенно.
В отличие от первой итерации, когда просто налаживались мосты между отделами, мы создали полностью кросс-функциональные команды, которые работали как единое целое. Все нужные для разработки и поддержки продукта специалисты были внутри команды, что свело к минимуму зависимости, тикетные войны и бюрократию.
К тому же такие кросс-функциональные команды оказались лучшим способом быстро прокачивать скиллы сотрудников.
Порталы, рождающие единорогов
Поработав с экспертом по базам данных, ты волей-неволей начинаешь думать о производительности запросов, обслуживании и нормализации. Развивая эти навыки, ты делаешь софт лучше. Нельзя поработать со спецом по инфраструктуре и не узнать про отказоустойчивость, сети и деплои без простоя. Эти навыки тоже помогают тебе делать софт лучше.
Когда компании жалуются, что негде взять крутых разработчиков-«единорогов», они упускают ключевой момент: кросс-функциональная команда берёт новичков и «прокачивает» их до уровня тех самых «единорогов», которых днем с огнём не сыщешь. Ты можешь прийти бэкендером, администратором баз данных или тестировщиком, но вырастешь в специалиста широкого профиля с кучей новых навыков.
Создание таких «порталов для единорогов» — самый ценный вклад, который руководители разработки могут дать компании. Закрывайте пробелы в навыках, нанимая нужных спецов, и создавайте среду, в которой эти навыки беспрепятственно передаются внутри команды.
Вливайтесь!
То, что выросло в отлаженный и повторяемый процесс трансформации команды, началось с простого действия — сесть и поработать вместе. Такого простого изменения оказалось достаточно для роста эмпатии и понимания, а за ним последовала целая серия улучшений.
Взгляд на бесконечную «простыню» логов стал поворотным моментом, который привёл к самому здоровому и человечному подходу в DevOps.
Тогда у нас не было исследований, чтобы это доказать, но автоматизация деплоев, общие цели, наблюдаемость, работа небольшими порциями и непрерывная доставка — всё это ведёт к лучшим результатам для людей, команд и всей компании. Когда DevOps делают правильно, выигрывают все.
Удачных деплоев!
P. S.
Читайте также в нашем блоге: