Обработка сбоев во время вашего перехода к CD и DevOps

В этом гостевом посте Пол Свартаут, ИТ-эксперт и автор книги Непрерывная доставка и DevOps — краткое руководствообъясняет, как справляться со сбоями на пути внедрения CD и DevOps.

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

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

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

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

Если вы используете гибкие методы, такие как схватка или канбан, для внедрения CD и внедрения DevOps, вы сможете относительно быстро изменить направление, не препятствуя прогрессу.

Хорошо, так что это все очень позитивный психологический настрой (PMA) и может быть воспринято некоторыми из вас, более циничными, чем остальные, как болтовня и банальности менеджмента, поэтому давайте рассмотрим сценарий с участием вымышленной ИТ-компании под названием ACME systems.

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

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

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

Однако если бы актив А был готов первым, ему пришлось бы сидеть и ждать — иногда в течение нескольких дней или недель. Транзакция развертывания начала мешать Непрерывная доставка (CD).

Вот простой процесс, который в системах ACME называется транзакцией развертывания:

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

Раньше это не было проблемой, так как скорость выпуска релизов была очень низкой, а активы были собраны вместе. Системы ACME теперь могли развертываться в рабочей среде очень быстро, и теперь возникла новая проблема: в каком порядке развертывать? Было проведено много дискуссий и рассмотрены сложные варианты, но в итоге решение было довольно простым: сдвинуть границы транзакции развертывания и разрешить полное интеграционное тестирование до того, как активы будут отправлены в производство.

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

На следующей диаграмме показана измененная граница транзакции развертывания:

Таким образом, у ACME был потенциальный провал, который мог бы полностью подорвать их внедрение CD и DevOps. Проблема стала очень заметной и было задано много вопросов. Последователи начали сомневаться в новаторах, а отстающие заговорили. Благодаря старому доброму сотрудничеству и честным обсуждениям проблема была быстро решена.

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

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

Процессы, которые невозможно повторить

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

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

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

Давайте рассмотрим очень простой пример: если вы инженер-программист, вы будете использовать IDE для написания кода и будете использовать компилятор для создания двоичного файла для развертывания. Если вы администратор базы данных (DBA), вы Я буду использовать программу администратора SQL для управления вашими базами данных и написания SQL. Вы ожидаете, что эти инструменты будут работать в 100% случаев и давать стабильные и воспроизводимые результаты; вы открываете исходный файл, и IDE открывает его для редактирования, и вы выполняете какой-то SQL, а инструмент администрирования SQL запускает его на сервере.

Если ваши инструменты продолжают давать сбои или дают неожиданные результаты, вы будете немного расстроены (мягко говоря) и, несомненно, воздержитесь от использования этих инструментов снова. Это может свести вас с ума.

То же самое касается инструментов (технических и нетехнических), которые вы создаете и/или внедряете для внедрения CD и DevOps. Эти инструменты должны быть такими же (если не лучше) программным обеспечением, которое создает ваша команда.

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

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

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

Мы уже рассмотрели потенциальные препятствия, с которыми вы столкнетесь в отношении корпоративных правил, бюрократии и стандартов. Только подумайте, какое удовольствие вы получите, убеждая привратников в том, что CD и DevOps не являются рискованными, если вы не можете обеспечить стабильные результаты для повторяющихся задач. Ладно, может быть, веселье — не то слово; может быть, боль лучше.

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

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

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