В идеале для всех повторяющихся действий в эксплуатации мы должны знать следующее: какое действие нужно произвести, кто для этого нужен, какие шаги требуются для его выполнения и так далее. К примеру, «мы знаем, что релиз стабильной окончательной версии происходит в четырнадцать этапов, требует привлечения четырех команд и последние пять раз в среднем на это требовалось три дня».
Точно так же, как мы реализуем требования заказчиков в разработке, мы можем создать четко определенные «требования инженеров эксплуатации». В них отражаются действия, повторяющиеся во всех проектах (например, развертывание, вопросы безопасности и производительности и так далее). С помощью таких требований мы согласовываем работу отделов разработки и эксплуатации и упрощаем планирование, а также получаем на выходе более стабильные результаты.
Используйте технологии, работающие на достижение целей компании
Когда одна из наших целей — максимизировать продуктивность разработчиков, а архитектура у нас — сервис-ориентированная, то небольшие команды могут писать свои приложения на наиболее подходящем для них языке и в оптимальной среде разработки. В некоторых случаях такой подход лучше всего согласуется с целями компании.
Однако есть ситуации, где происходит обратное, например когда поддержка важного сервиса лежит на одной команде и только она может устранять неполадки и вносить изменения. В результате в системе появляется узкое место. Другими словами, продуктивность команды оптимизирована, но при этом оказалась в противоречии с целями компании.
Такое часто происходит, когда за все аспекты поддержки сервиса отвечает только одна функционально ориентированная группа по эксплуатации. В такой ситуации нужно сделать так, чтобы отдел эксплуатации мог влиять на то, какие компоненты используются в производственной среде, или же снять с них ответственность за неподдерживаемые платформы.
Если у нас нет готового списка поддерживаемых в эксплуатации технологий, составленного при участии отделов разработки и эксплуатации, нужно пройтись по инфраструктуре производственной среды и задействованным в ней сервисам, а также по их текущим зависимостям, чтобы найти компоненты, создающие непропорционально большой риск сбоев или незапланированных работ. Наша цель — определить технологии, которые:
• замедляют или мешают рабочему процессу;
• являются причиной большого количества незапланированной работы;
• являются причиной большого количества запросов на поддержку;
• плохо соответствуют целям в плане характеристик архитектуры (например, производительность, стабильность, безопасность, надежность, бесперебойность работы).