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
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
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
Forwarded from Mops DevOps
AWS re:Invent 2021 — DevOps and Developer Productivity
https://www.youtube.com/playlist?list=PL2yQDdvlhXf8IJuIGCoPbO2HXxWFFml8Z
#reInvent #videos #devops
https://www.youtube.com/playlist?list=PL2yQDdvlhXf8IJuIGCoPbO2HXxWFFml8Z
1 Using feature flags to avoid downtime during migrations2 The journey from telemetry to business metrics3 OutSystems and AWS: The modern application platform for the cloud4 On AWS, details matter: Why full-stack observability wins5 Deploying container applications with cloud-native CI/CD pipelines6 Enterprise networking and SD-WAN with Cisco and AWS7 Enabling decentralized development teams with a shared services platform8 Incorporating continuous resilience in your development ecosystem9 Observing your applications from development through production10 Write, deploy, and provision cloud resources with AWS Developer Tools11 Infrastructure as code and modern data resilience on AWS12 Modern and confident: DevSecOps for enhanced cloud security13 Slack is the digital HQ for AWS developers and DevOps teams14 How to reuse patterns when developing infrastructure as code15 Amazon Builders' Library: Operational Excellence at Amazon16 Best practices for securing your software delivery lifecycle17 Building with the new AWS SDKs for Rust, Kotlin, and Swift18 Cloud-native operations: Agility and speed through distributed ownership19 Automating cross-account CI/CD pipelines [repeat]20 Automating cross-account CI/CD pipelines [repeat]21 What's new with AWS CloudFormation and AWS CDK22 DevOps revolution [repeat]#reInvent #videos #devops
Reminder, AWS Tech Conference June 30 Online, and great news - now with Dr. Werner Vogels himself!
Hey there! With our friends from AWS User Group, we want to invite you to a special AWS Tech Conference #StandWithUkraine🇺🇦
🔥Dr. Werner Vogels, CTO at Amazon will be a keynote!
He’ll talk about Next-Gen Cloud Computing.
Also, 12 speakers from AWS, AWS User Groups, AWS heroes and Ukrainian AWS professionals will talk about #DevOps, #data та #backend.
Some of the topics: scaling AWS Infrastructure, enabling public API in days with AWS Athena, AWS WAF & Firewall Manager, Serverless patterns, IT transformation in multi-cloud era, choosing the right data store.
When? June 30
Where? Online
How to join?
👉🏻Register for free: https://bit.ly/3HFXw4u
OR buy a charity ticket - all profit will go to Ukrainian charity funds.
Hey there! With our friends from AWS User Group, we want to invite you to a special AWS Tech Conference #StandWithUkraine🇺🇦
🔥Dr. Werner Vogels, CTO at Amazon will be a keynote!
He’ll talk about Next-Gen Cloud Computing.
Also, 12 speakers from AWS, AWS User Groups, AWS heroes and Ukrainian AWS professionals will talk about #DevOps, #data та #backend.
Some of the topics: scaling AWS Infrastructure, enabling public API in days with AWS Athena, AWS WAF & Firewall Manager, Serverless patterns, IT transformation in multi-cloud era, choosing the right data store.
When? June 30
Where? Online
How to join?
👉🏻Register for free: https://bit.ly/3HFXw4u
OR buy a charity ticket - all profit will go to Ukrainian charity funds.
👍5❤🔥3💩3🔥2
A very useful set of ready-made instructions for devops on AWS:
https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/welcome.html
All popular topics with specific implementation steps:
🔸Analytics
🔸Cloud-native
🔸Containers & microservices
🔸Cost management
🔸Data lakes
🔸Databases
🔸DevOps
🔸End-user computing
🔸Hybrid cloud
🔸Infrastructure
🔸IoT
🔸Machine learning & AI
🔸Management & governance
🔸Messaging & communications
🔸Migration
🔸Modernization
🔸Networking
🔸Operating systems
🔸Operations
🔸Security, identity, compliance
🔸Serverless
🔸Software development & testing
🔸Storage & backup
🔸Websites & web apps
#devops
https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/welcome.html
All popular topics with specific implementation steps:
🔸Analytics
🔸Cloud-native
🔸Containers & microservices
🔸Cost management
🔸Data lakes
🔸Databases
🔸DevOps
🔸End-user computing
🔸Hybrid cloud
🔸Infrastructure
🔸IoT
🔸Machine learning & AI
🔸Management & governance
🔸Messaging & communications
🔸Migration
🔸Modernization
🔸Networking
🔸Operating systems
🔸Operations
🔸Security, identity, compliance
🔸Serverless
🔸Software development & testing
🔸Storage & backup
🔸Websites & web apps
#devops
👍15