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

11 Dec 2022

Исследование DORA и его проблемы

Reading time: 2 minutes

Кажется, спустя полтора года после прочтения книги Accelerate наконец удалось кратко и компактно сформулировать в чем проблема с отчетом State Of Devops. Проблема в том, что в книге и отчете выпячивается та несомненно большая сложная часть работы по статистическим предсказаниям, которая однако по факту никому не нужна, и которая не имеет смысла. DORA статистически показали, что использование CI/CD приводит (“предсказывает”) к сокращению Lead Time, увеличению частоты поставки и снижению количества ошибок при развертывании.

06 Oct 2022

Путь развития разработчика в Infrastructure as Code

Reading time: 2 minutes

Недавно вышли новые роадмапы профессионального развития на https://roadmap.sh/ и они на мой взгляд очень хорошо помогают прояснить мой предыдущий пост про то, что подход Infrastructure as Code — это особая форма разработки. Я не уверен, что согласен с названиями роадмапов, но разделение на роадмапы мне кажется очень хорошо сделанным: Software Architect — список навыков указывают, что основные задачи это построение систем, состоящих из множества отдельно разрабатываемых компонентов (и интеграция этих компонентов между собой), коммуникация с разработчиками, другими архитекторами и руководством компании, и организация проекта.

25 Sep 2022

Инженерия и подход Infrastructure as Code

Reading time: 2 minutes

Подход “Инфраструктура как код” является ничем иным как особой формой разработки/программирования, и к этой форме разработки применимы большинство практик, принципов и паттернов, используемых в “классическом программировании”. В статье 1 мимоходом отлично прояснен этот вопрос через определение того, что такое “инженерия”: Ideally the construction design phase results first into an ontological model of the object system, i.e. a white-box model that is completely independent of its implementation. Gradually this ontological model is transformed into more detailed (and more implementation dependent) whitebox models, the last one being the implementation model.

31 Aug 2022

Об outsourcing

Reading time: 3 minutes

Интересным, но не совсем понятным в современной парадигме разработки становится место аутсорсинга в любом виде. В “классическом” аутсорсинге некая внешняя организация выполняет некие работы для создания системы, которая нужна заказчику, передает ее заказчику, и на этом жизнь проекта заканчивается. Иногда бывает постпроект в виде “поддержки”, но это чаще всего совсем другой режим работы. Иными словами, команда разработки создает систему, передает ее команде эксплуатации (которая как-то там ее поддерживает) и опционально подключается команда сопровождения для мелких багфиксов.

10 Aug 2022

Обеспечение жизненного цикла компонентов обеспечивающих жизненный цикл

Reading time: 1 minutes

Если ожидается, что наша система будет постоянно меняться, процесс эксплуатации становится важен настолько же, насколько важны и все остальные практики жизненного цикла – разработка, тестирование, сборка, интеграция и т.д. Более того, все эти практики жизненного цикла становятся практически настолько же важны, как и сами функции приложения – те, которые предоставляются внешним пользователям. Компоненты, обеспечивающие практики жизненного цикла (т.е. песочницы для разработчиков, автотесты, системы сборки, пайплайны CI/CD, система логирования и т.д.) становятся настолько же важны как и сами компоненты приложения — они теперь проектируются, разрабатываются, тестируются, эксплуатируются точно так же.

06 Aug 2022

Об принятие инженерных решений

Reading time: 5 minutes

Каждый раз когда мы говорим о реализации некоей системы (например, инфраструктурной платформы) одной из наших ключевых задач (возможно, важнейшей) будет принятие множества решений — как важных, так и не очень (нас интересуют важные). Эти решения самые разнообразные — решение о том, кто будет пользователями нашей системы, а кого оставляем за бортом, каким образом система будет устроена технологически, как мы ее будем реализовать и кто будет в нашей команде, и самое главное — будем ли мы эту систему реализовывать вообще, или будем жить дальше по старинке.

05 Jul 2022

Бирюзовый монолит

Reading time: 1 minutes

При разговоре о “бирюзовых организациях” или “аджайле” часто считают, что это организации плоские и без особой структуры. Мол хорошо мотивированные высококлассные специалисты могут сами организоваться наиболее эффективным образом. Но давайте вспомним про закон Конвея — “Организации проектируют системы, которые копируют структуру коммуникаций в этой организации”. Плоская структура без иерархии (либо развитой параллельной управляющей структуры в виде например HR или архитектурной функции) будет означать, что эта компания разрабатывает монолит. Свободное перемещение между командами и изменение их конфигурации и зон ответственности — то, что этот монолит будет сильносвязанным.

04 Apr 2022

Вовлеченность и Agile

Reading time: 1 minutes

(из архива 2020) Agile часто продают как способ повысить вовлеченность команды в процесс. На деле все наоборот — сначала вовлеченность, потом Agile. Возможно многие “серебряные пули” не работают именно потому что пытаются при помощи их решить то, что они требуют. К примеру, DevOps пытаются применять для того, чтобы с его помощью улучшить скорость поставки фич в продакшн, хотя на деле наоборот - улучшение такой скорости (помимо всего прочего) приводит к DevOps.

24 Mar 2022

Эволюция DevOps

Reading time: 3 minutes

15 лет назад DevOps начинался в попытке “подружить” разработку и эксплутацию – через культуру, обмен знаниями и совместную работу. Затем быстро развернулся в сторону ускорения поставки изменений из разработки в продакшн (активность Lean Value Stream Mapping), продолжился в понимание того, что программисты создают не просто код в репозитории (и даже не протестированный код в репозитории), а работающее приложение в продакшне (практики Observability и SRE). И последние несколько лет DevOps перешел к рассмотрению взаимодействие команд на масштабе (фреймворк Team Topologies).

15 Dec 2021

Тестирование в IaC

Reading time: 1 minutes

Подход “Инфраструктура как Код” (IaC) противопоставляется подходу “Infrastructure as Scripts” в том, что к коду (в отличие от скриптов) начинают применять практики обычные для программирования, например тестирование. Вот что имеет смысл тестировать в IaC: контракты (входы и выходы) модулей мутации параметров ( "${env}-${name}" или if env=prod then https should be enabled ) внешние ограничения (“не должно быть security group с полностью открытыми портами”) Сами ресурсы, которые мы создаем внутри модуля тестировать, конечно же, смысла не имеет – эта часть декларативна и уже протестирована провайдером ресурса.