Читаем Философия DevOps полностью

Философия DevOps

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

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

Согласно объяснению, приведенному Кромхаут,

при выборе между своим собственным сервисом и SaaS[49] оцениваются соответствующие расходы и преимущества, включая затраты, связанные с выполнением дополнительных работ (как затраты времени персонала, так и финансовые).

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

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

Как отмечает Кромхаут:

Создание рабочей инфраструктуры, определенной кодом, очень важно, поскольку мы стремимся все заменять в оперативном режиме, не отключая сайт на проведение профилактических работ. Рассматриваемый код может обрабатываться с помощью файла JSON, определяющего конфигурацию сервисов AWS, или «поваренных книг» Chef, или же с помощью Python (посредством Boto и Fabric). Мы отправляем запросы на включение подобного кода, который будет просмотрен и протестирован нашими коллегами перед выполнением слияния и развертывания. Критерий успеха в данном случае – создание рабочего кода. Это позволило нам отказаться от GitHub и наладить рабочий поток в стиле Канбан.

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

• Кто несет ответственность за принятие решений по выбору инструмента?

• Какие критерии используются для выбора инструмента, его оценки и опыта использования?

• Что является главным при выборе инструмента с точки зрения разработчика и заказчика?

Перейти на страницу: