Практики, подходы, процессы, инструменты

На митапе в ИТМО мы с ребятами затронули важную штуку: что такое практики, подходы, процессы и как они разделены (или объединены) в разных компаниях.

А сегодня оказалось что даже у нас не все понимают разницу.

Ну что ж. Подход — это культура, может быть даже методология, на основе которой мы действуем. Например, девопс — это подход. Весь, целиком. Считайте как философия, религия, способ работы, жизни. Туда же можно отнести SRE.

Практики. Это методы, с помощью которых мы реализуем ценности подходов. Например, ci/cd — непрерывная интеграция и поставка, эджайл, Инфраструктура как код, постмортемы, код-ревью, автотесты и прочие штуки, которые делают нашу жизнь и работу лучше, соответствуя подходам.

Процесс — он ближе к организационной истории, можно сказать это рельсы для практик. Без хорошего процесса практики повисают в "нигде" и не используются. Поэтому, хорошая практика поддерживается процессом, не теряется и используется постоянно. Например — процесс разобра инцидентов, онбординг, релизный процесс, процесс дежурства.

Инструмент или технология — это уже конкретный туллинг. Например, гитлаб, с его особенностями, эластик с его сложностью, кубер как технология.

Важно помнить, что Люди - Процессы - Технологии — именно в таком порядке, сначала делаем хорошо людям, потом — ставим процессы, а потом уже копаем в технологии.

спасибо, ЖПТ, заменил ссылки битые на реальные))

Подходы:
- DevOps — культура объединения Dev и Ops
[DevOps Explained by Atlassian](https://www.atlassian.com/devops)
- Agile — гибкая итеративная разработка
[Agile Manifesto](https://agilemanifesto.org/)
- SRE — надежность через программирование
[Google SRE Book Summary](https://landing.google.com/sre/book.html)
- DevSecOps — безопасность в разработке
[DevSecOps Guide by Microsoft](https://docs.microsoft.com/en-us/security/devsecops/)
- Platform Engineering — внутренние платформы для разработчиков
[Thoughtworks Platform Engineering](https://www.thoughtworks.com/radar/techniques/platform-engineering)

---

Практики:
- Continuous Integration (CI) — частое слияние и автоматические сборки
[CI Best Practices by Martin Fowler](https://martinfowler.com/articles/continuousIntegration.html)
- Continuous Delivery (CD) — автоматический деплой
[Continuous Delivery Book by Jez Humble](https://continuousdelivery.com/)
- Infrastructure as Code (IaC) — инфраструктура как код
[Terraform Getting Started](https://learn.hashicorp.com/terraform)
- Автоматизированное тестирование
[Testing Pyramid by Mike Cohn](https://martinfowler.com/articles/practical-test-pyramid.html)
- Мониторинг и алерты
[Monitoring Best Practices by Honeycomb](https://www.honeycomb.io/blog/best-practices-for-observability)

---

Процессы:
- CI/CD pipeline — последовательность шагов от кода до релиза
[Building a CI/CD Pipeline by CircleCI](https://circleci.com/blog/what-is-ci-cd/)
- Incident Management — управление инцидентами
[Incident Management 101 by PagerDuty](https://www.pagerduty.com/incident-response/incident-management/)
- Change Management — управление изменениями
[ITIL Change Management Overview](https://www.axelos.com/best-practice-solutions/itil/what-is-itil)
- Release Management — координация релизов
[Release Management Guide by Atlassian](https://www.atlassian.com/continuous-delivery/release-management)
- Knowledge Sharing & Communities — обмен знаниями
[Creating Knowledge Sharing Culture](https://www.tinypulse.com/blog/creating-a-knowledge-sharing-culture-in-the-workplace)

---

Технологии (инструменты):
- Jenkins / GitLab CI / AWS CodePipeline — CI/CD системы
[Jenkins Documentation](https://www.jenkins.io/doc/), [GitLab CI Docs](https://docs.gitlab.com/ee/ci/), [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
- Kubernetes / Docker — контейнеризация и оркестрация
[Kubernetes Official](https://kubernetes.io/docs/home/), [Docker Docs](https://docs.docker.com/)
- Terraform / CloudFormation — Infrastructure as Code
[Terraform Documentation](https://www.terraform.io/docs), [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
- Prometheus / Grafana / Datadog — мониторинг и визуализация
[Prometheus Docs](https://prometheus.io/docs/introduction/overview/), [Grafana Labs](https://grafana.com/docs/grafana/latest/), [Datadog Monitoring](https://www.datadoghq.com/monitoring/)
- Vault / AWS Secrets Manager — управление секретами
[HashiCorp Vault](https://www.vaultproject.io/docs/), [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)

мое лицо когда (всегда)

быть лучше и баланс

сколько ни рефлексировал на тему амбиций и достигаторства — всё одно: это лишнее

мотивировать себя нужно через одно — если ты понимаешь что ты хочешь — делай это. если не понимаешь — изучай, пробуй и делай, так и придешь к тому, что хочешь. или не придешь?

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

не стоит постоянно гнаться, ведь любой спринт (хехе) однажды должен закончиться. но и не стоит опускать руки и сидеть на попе ровно годами. важен баланс.

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

лучшие практики — не залог успеха. и в этом тоже нужен баланс.

как я для себя определяю баланс? наверное, пока я приношу пользу и мои знания/навыки/действия/слова полезны моему окружению — я всё делаю правильно. инженер никогда не перестает учиться и расти.

собеседования

одной из любимых частей моей работы всегда были собеседования (нет, я не про хопанье, гусары!)

да, они отнимают много времени и в периоды активного найма, в моем и без того плотном графике, выкроить время хотя бы на два в неделю сложно. а приходилось по 3-5 человек собеседовать

при этом я проводил и классические технички, и топ-грейдинги и комбо для лидов.

но самое интересное что в каждом интервью я нахожу что-то новое и никогда не чувствую рутинности действия. разные люди, разные настроения, разные повороты

а ещё, наверное, я повидал столько разных инженеров и менеджеров, что могу, при должном усилии, как-то их классифицировать (но пока не хочу)

кстати, зачастую собеседование воспринимается как «мы проверяем кандидата», а ведь это игра в обе калитки и собеседуемый может (и должен!) задавать вопросы. всегда удивляет (и обычно ставит крест) собеседник, говорящий «у меня нет вопросов»

небось соскучились по докладам от меня?

как и говорил раньше — я в ПК bigtechnight, отбирал в трек ламоды самые крутые доклады от крутых спикеров. пять крутых докладов от шести (!!) спикеров ждут вас (и нас) в офисе ламоды и (потом) в записи.

но мало того, один из докладов — конечно от меня. однако, подождите, там будет два спикера — со мной будет Юля (а у Юли нефиговый такой бэкграунд в бигтехах) и мы поговорим о том как You Build It You Run It существует и как мы в этом всём варимся.

мало? тогда давайте еще анонс — я на хард-треке ламоды на bigtechnight еще и ведущий!

продано? тогда го! Lamoda Tech

итерации и фазы

вроде уже говорилось, но повторю.

хочется сразу взять и сделать. с первого раза идеально, как задумал и по лучшим лекалам и соблюдая все практики. но не получается.

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

разделите проект на стадии или фазы. не пресловутое "давайте слона есть по кусочкам" (кто вообще ест слонов?!), но именно "я сделаю МВП или ПоК и потом уже пойму куда ведет дальше нас"

если твой ПоК занимает больше спринта времени — упрощай.

если твой МВП сразу работает как надо — выкатывай и отдавай в эксплуатацию.

а если нужны доработки — сразу пиши задачи в бэклог. отдавай техдолг. заложи на это время и ресурс.

но делай, делай и получай результат, улучшай, делай еще лучше, но не парься, если не получилось сразу идеально и целиком.

привет big tech night

привет, devoops

https://events.yandex.ru/events/bigtechnight/records ищите тут материалы с BTN!

привет, скейл

это фото того стоило, граждане))
сыч теперь независимый эксперт и еще и звезда стенд апа!

Кто нибудь расскажет мне как в бигтехах уживаются следующие взаимоисключающие параграфы?

1. Проблемы с софтом.
> Вечная бесконечная сборка-пересборка. Добрая половина времени разработки уходит на сборку.
> Отсутствие возможности запуска некоторых приложений вне прода во время разработки,
> Лапшекод в котором невозможно разобраться
> Проблемы с процессами, работяги гонят друг на друга и пытаются перекинуть свою работу на других

2. Все работяги как на подбор. Дохера вумные, за спиною книжки и небритые подмышки. Процесс найма, как будто там рокетсаенс на каждом шагу.

Почему сильные кадры делают слабо?

ретро

важно: ретро это вам не спринт-ревью и звать туда абы кого не стоит. там должна быть только команда. только мы, кому есть что обсудить. над чем по рефлексировать.

на ретро можно хвастаться, ругаться, благодарить. но все должно быть подкреплено фактами.

рекомендую вообще использовать конструкцию с фактами. то есть: не «Вася опять сделал лажу», а «Василий не успел разобраться в задаче и сделал её неверно, задачу не приняли». или не «Вася красава!», но «Вася смог сделать 5 задач за спринт».

то есть, к этой самой конструкции можно применить действие. часто на ретро возникают обсуждения и задачи процессной части.

очевидно, что для «плохих» карточек действия обязательны, а для хороших? тоже! но можно их делать в формате: «чтобы все делали так же хорошо, нам нужно» или «улучшить постановку задач и перед взятием в работу проверять что все в команде понимают требования».

ретро может превращаться в нытинг. а фасилитатору нужно иметь силу воли и строгость модерации, чтобы все стало продуктивным.

задачи с ретро берутся в работу с высоким приоритетом.

не делай всё сам

для менеджера свойственно проводить все встречи самому. это зовется "лидировать".

но ведь нет, есть такое понятие "фасилитация". я долго держал его в негативной коннотации, но потом понял — помощь и сопровождение — вот что нужно вкладывать в фасилитацию.

а фасилитировать может кто угодно, не обязательно менеджер. а значит — вести встречи, следить за исполнением процесса и помогать — тоже!

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

и да, конечно, вся команда — это единое фасилитирующее. и менеджер или лид — лицо, принимающее решение и ответственность.

но если менеджер будет делать всё сам и завернет всё на себя — ему не стоит переходить дорогу не поглядев по сторонам.