«You Build It, You Run It» vs «Девопс-инженер – суровая правда жизни»
Умные люди здесь жарко дискутировали на сотню комментариев, что же правильней-реальней.
▪️ Точка зрения 1. DevOps — это (отдельный) человек (девопс-инженер или несколько, команда, несколько команд), который занимается CI/CD процессом.
▪️ Точка зрения 2. DevOps — это подход «You Build It, You Run It».
Кроме этого, конечно, к обоим можно добавить, что это культура, набор лучших практик и так далее.
Однако главный вопрос: девопс — это отдельные специально обученный человек (люди), который(-е) "делают девопс" или же при таком подходе это лишнее звено. А в "правильном варианте" практики девопса воплощают разные члены команды, в первую очередь сами разработчики (кто разрабатывает, тот же деплоит, обновляет, мониторит и так далее).
Я (категорически) придерживаюсь варианта «You Build It, You Run It», понимая, что в «обычном случае» это не так. Однако считаю, что нужно добавить "пока" плюс, опять же, всегда правильно помнить и напоминать, как оно должно быть.
Поделитесь, пожалуйста, своим взглядом на эту проблему («You Build It, You Run It — this is real DevOps») в комментариях.
⁉️ Опрос «DevOps — это (отдельный) человек (люди)» vs «You Build It, You Run It».
#devops
Умные люди здесь жарко дискутировали на сотню комментариев, что же правильней-реальней.
▪️ Точка зрения 1. DevOps — это (отдельный) человек (девопс-инженер или несколько, команда, несколько команд), который занимается CI/CD процессом.
▪️ Точка зрения 2. DevOps — это подход «You Build It, You Run It».
Кроме этого, конечно, к обоим можно добавить, что это культура, набор лучших практик и так далее.
Однако главный вопрос: девопс — это отдельные специально обученный человек (люди), который(-е) "делают девопс" или же при таком подходе это лишнее звено. А в "правильном варианте" практики девопса воплощают разные члены команды, в первую очередь сами разработчики (кто разрабатывает, тот же деплоит, обновляет, мониторит и так далее).
Я (категорически) придерживаюсь варианта «You Build It, You Run It», понимая, что в «обычном случае» это не так. Однако считаю, что нужно добавить "пока" плюс, опять же, всегда правильно помнить и напоминать, как оно должно быть.
Поделитесь, пожалуйста, своим взглядом на эту проблему («You Build It, You Run It — this is real DevOps») в комментариях.
⁉️ Опрос «DevOps — это (отдельный) человек (люди)» vs «You Build It, You Run It».
#devops
Telegram
Sebor▂▅▇█▓▒░ in aws_notes_chat
Все же не согласен с рекомендацией. Я бы рекомендовал нанять дево пса 😏
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
Несколько месяцев как учу студентов AWS DevOps. С нуля, то есть совсем — абсолютно без опыта, да ещё и без желания учиться. 😀
Какие выводы сделал для себя, перелопатив кучи материалов, просмотрев сотни часов видео, курсов на бесплатных и платных платформах.
🔸 У новичков (кто реально с нуля) шансов найти что-то адекватное по столь популярной теме DevOps (специфика AWS уже вторично):
▪️ из бесплатного-доступного — шансов 0-5%
▪️ из платного — 10-15%
🔸 Научить с полного нуля можно кого угодно — опыт, прошлое образование, пол не имеют значения — это факт.
🔸 Рулят у студентов не способности, интеллект и прочие "этому дано", а самоконтроль и целеустремлённость.
🔸 Вариант самообразования — любые курсы платные/бесплатные и т.п. — подходят лишь ~15%. Остальные 85% без самоконтроля и вдолгую, в результате просто оставят негативные комментарии о желающих лишь заработать на них преподавателях, школах, курсах, академиях и т.д. Причём тоже будут правы и примерно с тем же раскладом.
Преподавательского опыта не было совсем, вышеописанные оценки сделаны больше со стороны студентов, к которым и отношу и себя, лишь с поправкой "с опытом".
#devops #курсы
Какие выводы сделал для себя, перелопатив кучи материалов, просмотрев сотни часов видео, курсов на бесплатных и платных платформах.
🔸 У новичков (кто реально с нуля) шансов найти что-то адекватное по столь популярной теме DevOps (специфика AWS уже вторично):
▪️ из бесплатного-доступного — шансов 0-5%
▪️ из платного — 10-15%
🔸 Научить с полного нуля можно кого угодно — опыт, прошлое образование, пол не имеют значения — это факт.
🔸 Рулят у студентов не способности, интеллект и прочие "этому дано", а самоконтроль и целеустремлённость.
🔸 Вариант самообразования — любые курсы платные/бесплатные и т.п. — подходят лишь ~15%. Остальные 85% без самоконтроля и вдолгую, в результате просто оставят негативные комментарии о желающих лишь заработать на них преподавателях, школах, курсах, академиях и т.д. Причём тоже будут правы и примерно с тем же раскладом.
Преподавательского опыта не было совсем, вышеописанные оценки сделаны больше со стороны студентов, к которым и отношу и себя, лишь с поправкой "с опытом".
#devops #курсы
👍17
В продолжение темы по обучению AWS DevOps совсем начинающих зафиксирую для себя некоторые выводы по материалу и инструментам.
▪️ Пожалел, что давал сначала Linux и спустя некоторое время добавил сети. Для совсем нулей нужно начинать сразу и то и то, либо даже сначала лишь сети.
▪️ Был прав, что практически с самого начала стал давать Terraform (@ThomasStorm, сначала кратко, но был CloudFormation, чеслово! 😀) — даже без понимания основ, привычка у студентов мыслить и действовать в рамках IaC рулит.
▪️ С первого урока использовал CloudShell как базовый инструмент.
➕ Плюсы: CloudShell — лучший способ сразу подружиться и с AWS Console, и с Linux, и с AWS CLI/Terraform/CDK.
➖ Минусы — привыкают и всё делают через CloudShell, у которого есть некоторые ограничения по сравнению с обычными виртуалками.
▪️ Linux учили на RedHat, чтобы после было легче освоить Amazon Linux. Получилось проще, да, но можно-нужно сразу давать Amazon Linux.
▪️ Cети по курсам подготовки к CCNA — вне конкуренции, лишь нужно отсеивать вещи чисто по Cisco.
▪️ Адекватной информации на русском мало, но студенты однозначно предпочитают материал на родном, даже имея английский на intermediate уровне.
▪️ Адекватной информации на русском мало, но по некоторым темам она таки есть и местами даже самая лучшая.
▪️ Материалы на английском необходимо отбирать по произношению — нэйтив спикеры чаще хуже для понимания, нежели материал от не носителей языка.
▪️ Чем больше в курсе анимации, тем обычно он качественнее и круче.
Потому лайфхак для тех, кто выбирает платные курсы — смотрите, сколько там мультиков. Именно мультиков, то бишь анимации (причём не спецэффектов и не видео) — значит автор вложился и это точно будет круто, если вы как раз с нуля.
#devops
▪️ Пожалел, что давал сначала Linux и спустя некоторое время добавил сети. Для совсем нулей нужно начинать сразу и то и то, либо даже сначала лишь сети.
▪️ Был прав, что практически с самого начала стал давать Terraform (@ThomasStorm, сначала кратко, но был CloudFormation, чеслово! 😀) — даже без понимания основ, привычка у студентов мыслить и действовать в рамках IaC рулит.
▪️ С первого урока использовал CloudShell как базовый инструмент.
➕ Плюсы: CloudShell — лучший способ сразу подружиться и с AWS Console, и с Linux, и с AWS CLI/Terraform/CDK.
➖ Минусы — привыкают и всё делают через CloudShell, у которого есть некоторые ограничения по сравнению с обычными виртуалками.
▪️ Linux учили на RedHat, чтобы после было легче освоить Amazon Linux. Получилось проще, да, но можно-нужно сразу давать Amazon Linux.
▪️ Cети по курсам подготовки к CCNA — вне конкуренции, лишь нужно отсеивать вещи чисто по Cisco.
▪️ Адекватной информации на русском мало, но студенты однозначно предпочитают материал на родном, даже имея английский на intermediate уровне.
▪️ Адекватной информации на русском мало, но по некоторым темам она таки есть и местами даже самая лучшая.
▪️ Материалы на английском необходимо отбирать по произношению — нэйтив спикеры чаще хуже для понимания, нежели материал от не носителей языка.
▪️ Чем больше в курсе анимации, тем обычно он качественнее и круче.
Потому лайфхак для тех, кто выбирает платные курсы — смотрите, сколько там мультиков. Именно мультиков, то бишь анимации (причём не спецэффектов и не видео) — значит автор вложился и это точно будет круто, если вы как раз с нуля.
#devops
👍32