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 выходит за рамки одного человека и связана с работой команд/проектов и в целом организации процессов в компании. В результате при внедрении 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
The GitLab Handbook
All Remote
GitLab is one of the world's largest all-remote companies
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
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