tgoop.com/devops_architecture/44
Last Update:
В противопоставлении document-centric и software-defined подходов я намеренно опустил один важный момент.
Представим, что нас интересует некий целевой процесс в организации, который будет давать нужный нам результат. Например, быструю и надежную доставку фич в продакшн. Или снижение рутины у команд сопровождения. Или повышение надежности релизов.
Мы проектируем этот процесс, чтобы получить этот самый результат — например, описываем чеклисты для перехода между активностями в этом процессе, или выделяем стадии для контроля качества доставляемой фичи.
Мы можем каждую из активностей в этом процесе описать в виде подробного документа, дать с ним ознакомиться сотрудникам, проводить регулярное обучение и адаптировать в виде инструкций.
Либо можно для каждой из активностей написать портянку YAML, написать тесты и CI/CD для раскатки этого YAML, перевести на разработанные скрипты автоматизации все процессы разработки.
Для каждой активности назначить ответственного сотрудника, который будет регулярно обновлять и дорабатывать регламенты (в случае документоцентричного подхода) или дописывать новый YAML по запросу разработчиков (в случае кодоцентричного подхода).
Только что я намеренно еще раз пропустил тот же самый важный момент. В обоих случаях нас интересует не просто регламентация или автоматизация шагов процесса, а тот результат, который мы получаем в итоге.
Вместо методологии DevOps появились devops-инженеры ровно в тот момент когда мы из software-defined процессов убрали ориентацию на результат и заменили ее автоматизацией отдельных шагов.
BY Об DevOps и архитектуру
Share with your friend now:
tgoop.com/devops_architecture/44