Времена изменились. Еще пять лет назад мы оставляли работу «по вызову» таинственной «команде DevOps», которая обеспечивала бы работу наших API и веб-сайтов.
Крайне важно, чтобы каждый разработчик в команде знал не только о том, как создавать код, но и как его доставлять и поддерживать .
Как вы можете гарантировать, что все разработчики, от младшего до старшего руководителя, знают, как эффективно поддерживать системы, которые они создают?

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


С юных лет меня учили фундаментальному поведению, чтобы повысить уверенность в чем-то: практика совершенствует . Но есть проблема.
Единственный способ узнать о поддержке производства - это броситься в глубину и сделать это. Вот как я это узнал. Шутки в сторону.
Мы находимся в 2019 году, и мы можем сделать вещи лучше.
Мастерская поддержки
После нашей ретроспективы о поддержке производства я решил поэкспериментировать с простым семинаром по поддержке.
Моими критериями успеха были:
Повысить уверенность каждого человека
есть список того, что было дерьмово о процессе поддержки производства
есть еще один список того, что было удивительного в процессе поддержки производства
Наконец, набор действий, которые команда может предпринять, чтобы сделать дерьмовые вещи потрясающими .
Поскольку давайте признаем, что разработчики не идеальны, а инструменты, журналы и модные информационные панели, которые мы настраиваем для поддержки производства, никогда не будут реально полезными или доступными.
Учитывая эти критерии, давайте подготовимся к семинару. Убедитесь, что у вас забронирован конференц-зал не менее чем на час.

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


Несколько примеров:
Сработал сигнал тревоги о емкости записи DynamoDB, что указывает на внезапный всплеск трафика
<Внешняя команда> сообщает, что они больше не получают данные из нашей системы.
<Внешняя группа> сообщает, что пользователи видят ошибку при загрузке веб-страницы. Там не было тревоги.
Пользовательский API вызывает тревогу, возвращая ошибки HTTP 500
Есть много способов, которыми вы можете написать сценарии - я сделаю так, чтобы это оставило ваш творческий мозг.
Установить сцену
Обратите внимание, что я был обобщен о том, что происходит в каждом сценарии. Причина в том, что всякий раз, когда происходит инцидент, вам будет предоставлена ​​информация или доказательства. Это может быть инцидент PagerDuty, сообщение Slack или постукивание по плечу от заинтересованного напарника.
Имея это в виду, откройте текстовый процессор, пыль архив слабины, скриншот некоторую реальную информацию от реальных производственных инцидентов и распечатать их . Вырежьте каждый кусочек информации и наклейте его на оборотную сторону соответствующей карточки с помощью клея или липкой ленты.
Если у вас нет недавних примеров, придумайте! Я использовал свой ближайший инструмент для редактирования изображений, чтобы создать некоторую «поддельную» информацию об одном из наших сервисов, как этот ниже.

Пример поддельного ежедневного сообщения Slack, отправленного одним из наших сервисов
Теперь, когда у вас есть свои сценарии, бросьте их все в небольшую картонную коробку или шляпу.
Настройте конференц-зал
Как и в ретроспективе, вы хотите настроить комнату собраний, чтобы команда могла объединить мысли всех людей во время собрания.
Я выбрал на стене три листа бумаги с заголовками « Что дерьмо », « Что удивительно » и « Действия », исходя из критериев, о которых я говорил выше. Каждый разработчик в комнате должен быть вооружен шулером и заметками Post-it, поскольку это совместный процесс.
Когда вы будете готовы, разложите шляпу по комнате и попросите каждого разработчика по одному сценарию. Имейте под рукой ноутбук для всех.
Начните расследование
Начиная с вас, прочитайте сценарий, а затем информацию, которую вам дали. Используйте свой ноутбук и примите меры, которые вы бы предприняли, чтобы исследовать проблему. Это означает, что войдите в свой облачный провайдер, чтобы проверить очереди недоставленных писем, выполнить поиск по журналу или запросить запись из вашей базы данных. Даже поддельное сообщение кому-то на платформе обмена сообщениями вашей работы или черновик поддельного электронного письма, чтобы собрать больше информации. Притворись, что там было мертвое письмо, и прими меры, чтобы воспроизвести его. Важно, чтобы вы установили стандарт того, насколько подробно вы хотите, чтобы каждый человек в комнате узнавал информацию об инциденте.


Пока ты все это делаешь, тебе нужен писец . Писец запишет все шаги, которые вы предпримете к заметкам, чтобы вы могли обратиться к ним позже. Разработчик должен сделать это, но это нормально, если на эту должность назначен ваш менеджер по доставке, менеджер по производству или волонтер UX Researcher.

Писец записывает некоторые действия, которые вы предприняли, и прикрепляет их к сценарию.
Как только вы закончите, с помощью писца объясните, почему вы предприняли шаги, которые вы сделали, чтобы решить проблему. Разговор о том, что было дерьмово об этом процессе. Насколько серьезным был сигнал тревоги, или почему инцидент произошел без тревоги, или почему панель управления была недоступна, или почему поиск журнала занял много лет, чтобы сказать вам, что случилось.
Поместите все дрянные вещи на стену в разделе « Что за дерьмо », как заметки в Post-it.

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

Некоторые примеры удивительных пост-своих
Передайте факел (или ноутбук в этом случае) и позвольте каждому человеку в комнате прочитать их сценарии и попытаться исследовать проблему позади сценария. Важно, чтобы вы дали понять, что все в порядке, если они не знают, что делать. В этом смысл встречи.
Завершите как можно больше сценариев и оставьте как минимум 15 минут на размышления над упражнением, поэтому установите таймер.
ретроспективный
Как только таймер истечет, у вас будет целая куча дерьмовых и удивительных постов на стене.
Теперь обсудите, какие действия может предпринять ваша команда . Это обязательства, которые ваша команда сделает для улучшения процесса.

Некоторые действия нашей команды из мастерской поддержки
И мы сделали! Ваша команда может расставить приоритеты для этих действий и помочь улучшить процесс поддержки производства.
Повторение
Я бы порекомендовал проводить семинар поддержки каждый месяц. Если у вас есть много действий, которые нужно предпринять, или много дерьмовых предметов, которые нужно исправить, проводите семинар чаще, пока ваша команда не будет уверена в своих процедурах поддержки. Это позволяет вашей команде пересмотреть действия, которые вы предприняли, и вашей команде постоянно быть в курсе усовершенствования процессов поддержки производства. Это также означает, что они будут постепенно становиться все более и более уверенными.
Мера
Отличный способ убедиться, что вы добились прогресса в улучшении процессов и уверенности команды, - отправив ежемесячный опрос своим разработчикам. Инструмент, такой как Polly , используемый через Slack, может быть настроен для автоматической отправки опроса с анонимными ответами. Вы можете задать один простой вопрос:
По шкале от 1 до 10, насколько вы уверены в поддержке < insert system или team name >?
Это обеспечит вас отличными боеприпасами для разговоров об улучшении процессов на каждом семинаре по поддержке.


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