Неизбежность, или Как приучить Devops-инженеров к проектированию

DevOps-инженеры легко становятся заложниками одной из двух моделей восприятия:
1) Задача DevOps — автоматизировать процессы, чтобы быстрее поставлять ценность конечному потребителю (при сохранении или росте качества), а значит DevOps’ы должны отвечать и за то, какую ценность несет поставка. То есть думать о бизнесе, стратегии и поддержке процессов разработки!
2) Задача DevOps — закрыть на уровне инфраструктуры все проблемы, которые можно снять с плеч разработки и бизнеса, чтобы те сосредоточились на «действительно важном». То есть решать проблемы, не задавать вопросы, подставлять «инфраструктурные костыли».

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

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

Мы рассмотрим 5 видов зрения, которыми должен обладать проектировщик: бизнес, системное, интеграционное, инфраструктурное и управленческое видения. Разберем на примерах, как связаны эти вижны между собой и с какими задачами помогают справиться. А также обсудим, как откалибровать зрение с помощью метрик.

Поделюсь опытом включения DevOps-инженеров в практики архитектурных решений (включая участие в формировании артефактов ADR и ADL — продемонстрирую шаблоны), инцидент-менеджмента (включая контроль PIR — поделюсь шаблоном), формирования корпоративной библиотеки инструментов.