DevOps и business playbook (или company playbook)

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

И действительно, а где посмотреть на примеры организиции процессов в IT компаниях — то, что выше и более общее, чем написание скриптов? Где взять аргументы в споре, почему неправильно не только деплоить на прод в пятницу вечером, но и вообще, как организовать эффективное взаимодействие при возникшем удалённом режиме работы?

Ответ есть — playbooks. Не которые ansible playbooks (из-за которых их так сложно нагуглить), а business (company) playbooks — открытые публичные описания, как устроены процессы внутри каких-то компаний.

Например, ваша компания перешла на удалённый режим работы и есть проблемы с выстраиванием взаимодействия (а они есть вне всяких сомнений) — обязательно почитайте GitLab playbook:

▫️ https://about.gitlab.com/company/culture/all-remote/
▫️ https://about.gitlab.com/handbook/

В свете успешно вышедшей на IPO организации, работающей на 100% удалённо не один год, у вас будут серьёзные аргументы в предложениях улучшить практики взаимодействия, в том числе пересекающиеся с DevOps.

Другой исключительно детальный и объёмный playbook от Microsoft:

▪️ https://microsoft.github.io/code-with-engineering-playbook/

Отличное чтиво, однозначно рекомендуется ознакомиться, т.к. это и есть набор best practices, что суть DevOps.

В дополнение некоторый список от других известных и не очень компаний:

🔹 https://www.atlassian.com/team-playbook
🔹 https://heap.io/resources
🔹 https://www.timble.net/playbook/
🔹 https://thoughtbot.com/playbook
🔹 https://www.kohactive.com/playbook/
🔹 https://www.fullstacklabs.co/playbook

А у вашей компании есть свой playbook? Используете ли подобные практики для улучшения DevOps в своей компании?

#devops #design

​​DevOps Guru для всей организации:

https://aws.amazon.com/ru/about-aws/whats-new/2021/11/amazon-devops-guru-multi-account-insight-aws-organizations/

Теперь можно выдать в девопс-аккаунте права для работы DevOps Guru со всей организацией (Delegated Administrator). С учётом того, что DevOps Guru стал поддерживать ещё больше EKS Insights метрик, то получается солидный инструмент.

Не вместо девопса, понятно – это больше для броского словца, но весьма полезный инструмент для девопса. Может быть дорогой, но хипстерский крутой и полезный. 😀

#DevOpsGuru #Organizations #devops

​​CI/CD best practices — AWS Whitepaper «Practicing Continuous Integration and Continuous Delivery on AWS»:

https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/testing-stages-in-continuous-integration-and-continuous-delivery.html

90% рекомендаций не привязаны к AWS, потому полезны для подавляющего большинства проектов/команд.

👍Do:
▪️ Treat your infrastructure as code
▫️▪️ Use version control for your infrastructure code.
▫️▪️ Make use of bug tracking/ticketing systems.
▫️▪️ Have peers review changes before applying them.
▫️▪️ Establish infrastructure code patterns/designs.
▫️▪️ Test infrastructure changes like code changes.
▪️ Put developers into integrated teams of no more than 12 self-sustaining members.
▪️ Have all developers commit code to the main trunk frequently, with no long-running feature branches.
▪️ Consistently adopt a build system such as Maven or Gradle across your organization and standardize builds.
▪️ Have developers build unit tests toward 100% coverage of the code base.
▪️ Ensure that unit tests are 70% of the overall testing in duration, number, and scope.
▪️ Ensure that unit tests are up-to-date and not neglected. Unit test failures should be fixed, not bypassed.
▪️ Treat your continuous delivery configuration as code.
▪️ Establish role-based security controls (that is, who can do what and when).
▫️▪️ Monitor/track every resource possible.
▫️▪️ Alert on services, availability, and response times.
▫️▪️ Capture, learn, and improve.
▫️▪️ Share access with everyone on the team.
▫️▪️ Plan metrics and monitoring into the lifecycle.
▪️ Keep and track standard metrics.
▫️▪️ Number of builds.
▫️▪️ Number of deployments.
▫️▪️ Average time for changes to reach production.
▫️▪️ Average time from first pipeline stage to each stage.
▫️▪️ Number of changes reaching production.
▫️▪️ Average build time.
▪️ Use multiple distinct pipelines for each branch and team.

👎Don’t:
▪️ Have long-running branches with large complicated merges.
▪️ Have manual tests.
▪️ Have manual approval processes, gates, code reviews, and security reviews.


#devops #best_practices