Об DevOps и архитектуру

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

Предположим, некий "devops-инженер" пишет разнообразную автоматизацию пайплайна SDLC для своей команды разработки.
- Его видимая работа состоит в написании различных автоматизаций на YAML. Эти задачи можно положить в таск-трекер и проконтролировать их выполнение.
- Следующий слой работы состоит в интеграции отдельных шагов пайплайна так, чтобы артефакты между ними передавались правильно и без ошибок. Эти задачи в таск трекер положить можно, но только либо в виде самого описания или definition of done задачи по реализации шага пайплайна, либо в виде багов — когда один шаг вроде бы интегрирован с другим, но дает неверные результаты. Причем, технически эту задачу отделить от первого шага вполне реально — я часто советую ребятам сделать два эти шага по отдельности, когда они буксуют над подобной составной задачей
- Слоем глубже находится построение поведения пайплайна, состоящего из нескольких шагов. Например, мы сперва публикуем контейнер в хранилище, дальше этот контейнер сканируем на уязвимости и подписываем ключом, и в конце разрешаем запуск контейнеров на средах только если они подписаны. Эту задачу можно положить в таск-трекер как набор отдельных задач, но для того чтобы реализовалась именно функциональность "разрешить запуск только контейнеров просканированных на уязвимости" нужно эти задачи или объединить в какой-нибудь эпик, или тщательно описать что должно происходить для каждой из задач, или описать весь процесс отдельным документом и прикрепить его к каждой из задач. Создание такого описания и декомпозиция его на тикеты может быть отдельной задачей перед собственно написанием автоматизации на YAML, и задачей окажется довольно немаленькой.
Ну или можно завести одну большую задачу "реализовать проверку подписи контейнеров", подразумевая всю эту цепочку, и отдать выяснять детали самому инженеру. Но тогда как состояние выполнения этой довольно немаленькой задачи, так и собственно способ ее реализации становятся плохо верифицируемыми для стороннего наблюдателя. Иными словами, если мы ставим такие достаточно большие составные задачи (или мини-проекты) мы должны быть уверены в том, что сотрудник умеет их решать, и решает их хорошо.
- Если идти еще глубже, мы приходим к построению принципов и стандартов работы пайплайна самого по себе, и как они будут интегрироваться с рабочим процессом команд разработки. Из этих принципов у нас появляются задачи на реализацию элементов функциональности пайплайна — т.е. задачи предыдущего слоя. Такой вид задач требует как знания предметной области ("как правильно строить пайплайны") с одной стороны, так и совершенно нетехнических компетенций с другой стороны — навыков анализа систем, планирования процессов и декомпозиции решений на элементарные задачи.

Все это хорошо, но какая здесь связь с DevOps?

Дело в том, что ориентация на результат, анализ сложных систем и планирование их реализации — это набор необходимых характеристик любого технического руководителя. Декомпозиция целевого решения на отдельные задачи тоже.
Вся суть "методологии DevOps" состоит в том, чтобы включать в активности по проектированию целевой системы не только функциональные и нефункциональные требования заказчика, но также и части системы связанные с Инфраструктурой и SDLC. Это не столько "методология" или "философия", сколько домен знания наподобие "проектирования интерфейсов" или "построения даталейков".
Скорее всего будучи руководителем, реализацию различных частей системы ты отдашь сотрудникам с соответствующей квалификацией.
В этот момент и возникает потребность в devops-инженерах, которые на деле являются такими же разработчиками как фронтендеры, тестировщики или разработчики на Java.

www.tgoop.com/devops_architecture/45

514 viewsedited  Mar 28, 2024 at 17:50

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

Предположим, некий "devops-инженер" пишет разнообразную автоматизацию пайплайна SDLC для своей команды разработки.
- Его видимая работа состоит в написании различных автоматизаций на YAML. Эти задачи можно положить в таск-трекер и проконтролировать их выполнение.
- Следующий слой работы состоит в интеграции отдельных шагов пайплайна так, чтобы артефакты между ними передавались правильно и без ошибок. Эти задачи в таск трекер положить можно, но только либо в виде самого описания или definition of done задачи по реализации шага пайплайна, либо в виде багов — когда один шаг вроде бы интегрирован с другим, но дает неверные результаты. Причем, технически эту задачу отделить от первого шага вполне реально — я часто советую ребятам сделать два эти шага по отдельности, когда они буксуют над подобной составной задачей
- Слоем глубже находится построение поведения пайплайна, состоящего из нескольких шагов. Например, мы сперва публикуем контейнер в хранилище, дальше этот контейнер сканируем на уязвимости и подписываем ключом, и в конце разрешаем запуск контейнеров на средах только если они подписаны. Эту задачу можно положить в таск-трекер как набор отдельных задач, но для того чтобы реализовалась именно функциональность "разрешить запуск только контейнеров просканированных на уязвимости" нужно эти задачи или объединить в какой-нибудь эпик, или тщательно описать что должно происходить для каждой из задач, или описать весь процесс отдельным документом и прикрепить его к каждой из задач. Создание такого описания и декомпозиция его на тикеты может быть отдельной задачей перед собственно написанием автоматизации на YAML, и задачей окажется довольно немаленькой.
Ну или можно завести одну большую задачу "реализовать проверку подписи контейнеров", подразумевая всю эту цепочку, и отдать выяснять детали самому инженеру. Но тогда как состояние выполнения этой довольно немаленькой задачи, так и собственно способ ее реализации становятся плохо верифицируемыми для стороннего наблюдателя. Иными словами, если мы ставим такие достаточно большие составные задачи (или мини-проекты) мы должны быть уверены в том, что сотрудник умеет их решать, и решает их хорошо.
- Если идти еще глубже, мы приходим к построению принципов и стандартов работы пайплайна самого по себе, и как они будут интегрироваться с рабочим процессом команд разработки. Из этих принципов у нас появляются задачи на реализацию элементов функциональности пайплайна — т.е. задачи предыдущего слоя. Такой вид задач требует как знания предметной области ("как правильно строить пайплайны") с одной стороны, так и совершенно нетехнических компетенций с другой стороны — навыков анализа систем, планирования процессов и декомпозиции решений на элементарные задачи.

Все это хорошо, но какая здесь связь с DevOps?

Дело в том, что ориентация на результат, анализ сложных систем и планирование их реализации — это набор необходимых характеристик любого технического руководителя. Декомпозиция целевого решения на отдельные задачи тоже.
Вся суть "методологии DevOps" состоит в том, чтобы включать в активности по проектированию целевой системы не только функциональные и нефункциональные требования заказчика, но также и части системы связанные с Инфраструктурой и SDLC. Это не столько "методология" или "философия", сколько домен знания наподобие "проектирования интерфейсов" или "построения даталейков".
Скорее всего будучи руководителем, реализацию различных частей системы ты отдашь сотрудникам с соответствующей квалификацией.
В этот момент и возникает потребность в devops-инженерах, которые на деле являются такими же разработчиками как фронтендеры, тестировщики или разработчики на Java.

BY Об DevOps и архитектуру