Меня зовут Тимур Батыршин. Я развиваю методологию DevOps и связанные с этим архитектурные и организационные подходы.
Менеджер практики Инфраструктура и лидер направления DevOps в AXENIX, член программного комитета конференции DevOpsConf, преподаватель в OTUS.
Это копия https://timurb.ru/ — не блог, а скорее база знаний и глоссарий. Статьи могут обновляться, при этом оставаться по одному и тому же адресу.
Здесь я размещаю как тексты своего авторства, так и чужие цитаты. Если это цитата обычно я ставлю ссылку на источник.
Тексты могут и будут дорабатываться со временем, это может происходить прямо внутри статей, не отдельными страницами.
Статьи также публикуются по адресам:
https://timurb.ru/
https://timurbatyrshin.medium.com/
Мои контакты:
Facebook: fb.com/tbatyrshin
LinkedIn: linkedin.com/in/timurb
Telegram: @TimurBatyrshin
Менеджер практики Инфраструктура и лидер направления DevOps в AXENIX, член программного комитета конференции DevOpsConf, преподаватель в OTUS.
Это копия https://timurb.ru/ — не блог, а скорее база знаний и глоссарий. Статьи могут обновляться, при этом оставаться по одному и тому же адресу.
Здесь я размещаю как тексты своего авторства, так и чужие цитаты. Если это цитата обычно я ставлю ссылку на источник.
Тексты могут и будут дорабатываться со временем, это может происходить прямо внутри статей, не отдельными страницами.
Статьи также публикуются по адресам:
https://timurb.ru/
https://timurbatyrshin.medium.com/
Мои контакты:
Facebook: fb.com/tbatyrshin
LinkedIn: linkedin.com/in/timurb
Telegram: @TimurBatyrshin
Различение между проектом и процессом
Из комментариев к обсуждению различия между проектом и процессом https://www.facebook.com/alex.turkhanov/posts/10227176872024711 :
- а) процесс не мобилизует ресурсы (проект мобилизует), он использует выделенные и зарезервированные под него;
- б) у процесса множественная причинность (у проекта токен-причинность), если мы сделаем вот такие действия над вот такими объектами, то из такой ситуации перейдем вот в такую;
- в) процесс есть инвариант , неизменная и неполная по составу и структуре основа для действий. Например, у Росатома есть процесс сооружения АЭС, события и действия, которые должны произойти, чтобы соорудить АЭС. Каждый отдельный экземпляр процесса сооружения порождает еще и проект сооружения, в рамках программы конкретной АЭС, в которой еще есть и куча процессов (проектов) эксплуатации и вывода из эксплуатации и пр.
Т.е., проект и процесс - это разные методы описания архитектуры действия.
В этом контексте начинает новыми красками играть понятие о Платформенной стратегии (https://platformdesigntoolkit.com/toolkit/) – она также мобилизует экосистему.
Кросспост:
https://timurb.ru/kb/project-vs-process/
https://timurbatyrshin.medium.com/8b873d6be48d
Из комментариев к обсуждению различия между проектом и процессом https://www.facebook.com/alex.turkhanov/posts/10227176872024711 :
- а) процесс не мобилизует ресурсы (проект мобилизует), он использует выделенные и зарезервированные под него;
- б) у процесса множественная причинность (у проекта токен-причинность), если мы сделаем вот такие действия над вот такими объектами, то из такой ситуации перейдем вот в такую;
- в) процесс есть инвариант , неизменная и неполная по составу и структуре основа для действий. Например, у Росатома есть процесс сооружения АЭС, события и действия, которые должны произойти, чтобы соорудить АЭС. Каждый отдельный экземпляр процесса сооружения порождает еще и проект сооружения, в рамках программы конкретной АЭС, в которой еще есть и куча процессов (проектов) эксплуатации и вывода из эксплуатации и пр.
Т.е., проект и процесс - это разные методы описания архитектуры действия.
В этом контексте начинает новыми красками играть понятие о Платформенной стратегии (https://platformdesigntoolkit.com/toolkit/) – она также мобилизует экосистему.
Кросспост:
https://timurb.ru/kb/project-vs-process/
https://timurbatyrshin.medium.com/8b873d6be48d
Тестирование в подходе Infrastructure as Code
Подход “Инфраструктура как Код” (IaC) противопоставляется подходу “Infrastructure as Scripts” в том, что к коду (в отличие от скриптов) начинают применять практики обычные для программирования, например тестирование.
Вот что имеет смысл тестировать в IaC:
- контракты (входы и выходы) модулей
- мутации параметров (
- внешние ограничения (“не должно быть security group с полностью открытыми портами”)
Сами ресурсы, которые мы создаем внутри модуля тестировать, конечно же, смысла не имеет – эта часть декларативна и уже протестирована провайдером ресурса.
Кросспост:
https://timurb.ru/kb/testing-the-iac/
https://timurbatyrshin.medium.com/a2df631c5aaa
https://www.facebook.com/tbatyrshin/posts/4708317799204114
Подход “Инфраструктура как Код” (IaC) противопоставляется подходу “Infrastructure as Scripts” в том, что к коду (в отличие от скриптов) начинают применять практики обычные для программирования, например тестирование.
Вот что имеет смысл тестировать в IaC:
- контракты (входы и выходы) модулей
- мутации параметров (
"${env}-${name}" или if env=prod then https should be enabled )- внешние ограничения (“не должно быть security group с полностью открытыми портами”)
Сами ресурсы, которые мы создаем внутри модуля тестировать, конечно же, смысла не имеет – эта часть декларативна и уже протестирована провайдером ресурса.
Кросспост:
https://timurb.ru/kb/testing-the-iac/
https://timurbatyrshin.medium.com/a2df631c5aaa
https://www.facebook.com/tbatyrshin/posts/4708317799204114
Эволюция DevOps
15 лет назад DevOps начинался в попытке “подружить” разработку и эксплутацию — через культуру, обмен знаниями и совместную работу. Затем быстро развернулся в сторону ускорения поставки изменений из разработки в продакшн (активность Lean Value Stream Mapping, https://www.atlassian.com/continuous-delivery/principles/value-stream-mapping), продолжился в понимание того, что программисты создают не просто код в репозитории (и даже не протестированный код в репозитории), а работающее приложение в продакшне (практики Observability и SRE, https://sre.google/sre-book/table-of-contents/). И последние несколько лет DevOps перешел к рассмотрению взаимодействия команд на масштабе (фреймворк Team Topologies, https://teamtopologies.com/).
Что при этом менее заметно, так это происходящая одновременно с этим эволюция корпоративной архитектуры:
- Сперва одно подразделение (Ops) предоставляло сервис пользователям при помощи инструментов, которые разрабатывает другое подразделение (Dev)
- Затем взгляд сместился на построение цепочки добавленной стоимости (Value Stream), которое включает как оба этих подразделения, так и новые роли (например Product)
- Сегодня же говорят о построении инфраструктурных платформ и выделение особых интеграционных команд (enabling teams) для создания гибкости на продуктовом ландшафте
По сути современный DevOps (и DevOps ближайшего будущего) и заключается в:
- предоставлении сервисов при помощи которых команды разработки сами могут строить свой рабочий процесс, при этом сами эти сервисы должны соответствовать стандартам качества заданным в организации (по ИБ, SLA и т.д.)
- создании на базе этих сервисов типовых решений для быстрого старта, которые каждая команда разработки может адаптировать под себя
- активностях по интеграции, обучению и передаче экспертизы для еще более быстрого старта команд разработки
- практиках SRE, которые по факту уходят от инфраструктурных команд в команды разработки
Важный вопрос, который встает в такой картине если хотя бы чуть-чуть отойти в сторону от разработки: зачем командам строить свои уникальные рабочие процессы? Зачем делать свои велосипеды? Почему не взять один стандартный процесс разработки, сделать его частично кастомизируемым и работать по нему?
Ответ на это достаточно простой: у разных продуктов и компонентов разная частота внесения изменений, разные “нефункциональные” требования (например, критичность для бизнеса, требования к доступности и нагрузке, или требования compliance), а часто и разный технологический стек (бэк, фронт, два вида мобилки). Один универсальный набор инструментов и процессов не подойдет для этих таких разных компонентов — для каких-то продуктов он может начать тормозить разработку, а для каких-то не будет обеспечивать необходимый уровень качества. С другой стороны слишком широкие возможности кастомизации затрудняют использование инструментов, и польза от точечной кастомизации “стандартного пайплайна” для маленьких низкокритичных компонентов с быстрым циклом разработки будет невелика.
Выход здесь лежит в построении типовых сценариев работы команд, и их самостоятельную адаптации под конкретные потребности команд по месту. Фокус при этом должен быть на простоту и скорость интеграции такого сценария (и его обновлений!) в повседневную жизнь команды. Другой важный момент: для команд должны быть видны явные преимущества использования этого сценария и предоставляемых сервисов по сравнению с созданием собственных велосипедов.
Это осуществимо при помощи списка составляющих перечисленных в середине статьи.
В случае старой парадигмы (ITIL/ITSM подход) это сделать невозможно, т.к. реинжениринг процессов дорог и ограничивает скорость изменений самих рабочих процессов.
Кросспост:
- https://timurb.ru/kb/devops-evolution/
- https://timurbatyrshin.medium.com/82d220c4afa1
- https://www.facebook.com/tbatyrshin/posts/5019698084732749
15 лет назад DevOps начинался в попытке “подружить” разработку и эксплутацию — через культуру, обмен знаниями и совместную работу. Затем быстро развернулся в сторону ускорения поставки изменений из разработки в продакшн (активность Lean Value Stream Mapping, https://www.atlassian.com/continuous-delivery/principles/value-stream-mapping), продолжился в понимание того, что программисты создают не просто код в репозитории (и даже не протестированный код в репозитории), а работающее приложение в продакшне (практики Observability и SRE, https://sre.google/sre-book/table-of-contents/). И последние несколько лет DevOps перешел к рассмотрению взаимодействия команд на масштабе (фреймворк Team Topologies, https://teamtopologies.com/).
Что при этом менее заметно, так это происходящая одновременно с этим эволюция корпоративной архитектуры:
- Сперва одно подразделение (Ops) предоставляло сервис пользователям при помощи инструментов, которые разрабатывает другое подразделение (Dev)
- Затем взгляд сместился на построение цепочки добавленной стоимости (Value Stream), которое включает как оба этих подразделения, так и новые роли (например Product)
- Сегодня же говорят о построении инфраструктурных платформ и выделение особых интеграционных команд (enabling teams) для создания гибкости на продуктовом ландшафте
По сути современный DevOps (и DevOps ближайшего будущего) и заключается в:
- предоставлении сервисов при помощи которых команды разработки сами могут строить свой рабочий процесс, при этом сами эти сервисы должны соответствовать стандартам качества заданным в организации (по ИБ, SLA и т.д.)
- создании на базе этих сервисов типовых решений для быстрого старта, которые каждая команда разработки может адаптировать под себя
- активностях по интеграции, обучению и передаче экспертизы для еще более быстрого старта команд разработки
- практиках SRE, которые по факту уходят от инфраструктурных команд в команды разработки
Важный вопрос, который встает в такой картине если хотя бы чуть-чуть отойти в сторону от разработки: зачем командам строить свои уникальные рабочие процессы? Зачем делать свои велосипеды? Почему не взять один стандартный процесс разработки, сделать его частично кастомизируемым и работать по нему?
Ответ на это достаточно простой: у разных продуктов и компонентов разная частота внесения изменений, разные “нефункциональные” требования (например, критичность для бизнеса, требования к доступности и нагрузке, или требования compliance), а часто и разный технологический стек (бэк, фронт, два вида мобилки). Один универсальный набор инструментов и процессов не подойдет для этих таких разных компонентов — для каких-то продуктов он может начать тормозить разработку, а для каких-то не будет обеспечивать необходимый уровень качества. С другой стороны слишком широкие возможности кастомизации затрудняют использование инструментов, и польза от точечной кастомизации “стандартного пайплайна” для маленьких низкокритичных компонентов с быстрым циклом разработки будет невелика.
Выход здесь лежит в построении типовых сценариев работы команд, и их самостоятельную адаптации под конкретные потребности команд по месту. Фокус при этом должен быть на простоту и скорость интеграции такого сценария (и его обновлений!) в повседневную жизнь команды. Другой важный момент: для команд должны быть видны явные преимущества использования этого сценария и предоставляемых сервисов по сравнению с созданием собственных велосипедов.
Это осуществимо при помощи списка составляющих перечисленных в середине статьи.
В случае старой парадигмы (ITIL/ITSM подход) это сделать невозможно, т.к. реинжениринг процессов дорог и ограничивает скорость изменений самих рабочих процессов.
Кросспост:
- https://timurb.ru/kb/devops-evolution/
- https://timurbatyrshin.medium.com/82d220c4afa1
- https://www.facebook.com/tbatyrshin/posts/5019698084732749
Прикрепил к каналу чат, можно посты обсуждать. Видимо появится начиная со следующих постов.
Об DevOps и архитектуру pinned «Меня зовут Тимур Батыршин. Я развиваю методологию DevOps и связанные с этим архитектурные и организационные подходы. Менеджер практики Инфраструктура и лидер направления DevOps в AXENIX, член программного комитета конференции DevOpsConf, преподаватель в OTUS.…»
Agile часто продают как способ повысить вовлеченность команды в процесс. На деле все наоборот — сначала вовлеченность, потом Agile.
Возможно многие “серебряные пули” не работают именно потому что пытаются при помощи их решить то, что они требуют.
К примеру, DevOps пытаются применять для того, чтобы с его помощью улучшить скорость поставки фич в продакшн, хотя на деле наоборот - улучшение такой скорости (помимо всего прочего) приводит к DevOps.
(из архива 2020)
Возможно многие “серебряные пули” не работают именно потому что пытаются при помощи их решить то, что они требуют.
К примеру, DevOps пытаются применять для того, чтобы с его помощью улучшить скорость поставки фич в продакшн, хотя на деле наоборот - улучшение такой скорости (помимо всего прочего) приводит к DevOps.
(из архива 2020)
При разговоре о "бирюзовых организациях" или "аджайле" часто считают, что это организации плоские и без особой структуры. Мол хорошо мотивированные высококлассные специалисты могут сами организоваться наиболее эффективным образом.
Но давайте вспомним про закон Конвея — "Организации проектируют системы, которые копируют структуру коммуникаций в этой организации".
Плоская структура без иерархии (либо развитой параллельной управляющей структуры в виде например HR или архитектурной функции) будет означать, что эта компания разрабатывает монолит. Свободное перемещение между командами и изменение их конфигурации и зон ответственности — то, что этот монолит будет сильносвязанным. Это действительно светлое будущее, или же мы движемся в будущее микросервисов?
Есть ли примеры организаций с плоской структурой, для которых это не наблюдается?
Но давайте вспомним про закон Конвея — "Организации проектируют системы, которые копируют структуру коммуникаций в этой организации".
Плоская структура без иерархии (либо развитой параллельной управляющей структуры в виде например HR или архитектурной функции) будет означать, что эта компания разрабатывает монолит. Свободное перемещение между командами и изменение их конфигурации и зон ответственности — то, что этот монолит будет сильносвязанным. Это действительно светлое будущее, или же мы движемся в будущее микросервисов?
Есть ли примеры организаций с плоской структурой, для которых это не наблюдается?