Download as PDF, PPTX
Uploaded byAndrey Rebrov
DevOps от и до - что, зачем и почему
Документ описывает концепцию DevOps, подчеркивая важность сотрудничества между разработчиками и операциями для повышения эффективности процессов разработки и развертывания программного обеспечения. Основные принципы включают создание культуры постоянного улучшения, быстрой обратной связи и управления через автоматизацию. Также приводятся модели внедрения DevOps и основные антипаттерны, препятствующие эффективному функционированию команд.
More Related Content
Similar to DevOps от и до - что, зачем и почему
![We're all DevOps [RU]](https://cdn.slidesharecdn.com/ss_thumbnails/copyofwerealldevopshereru-191218091450-thumbnail.jpg?width=640&height=640&fit=bounds)
DevOps от и до - что, зачем и почему
- 1. DevOps от и до Андрей Ребров Инженерный тренер ScrumTrek
- 3. Как разработчики видят администраторов
- 4. Как администраторы видят разработчиков
- 5.
- 6.
- 7.
- 8. Еще не все потеряно!
- 13. Agile Infrastructure • OperaQng at Cloud Scale • Ephemeral Infrastructure • FricQonless Infrastructure • Self Service OperaQons
- 14. Agile OperaQons • Products not Projects • Walk on Walk off Projects • Velocity of InnovaQon • ConQnuous Delivery • Enterprise Lean Startup
- 16. Что такое DevOps? • постоянный поток поставки ценности • быстрый цикл обратной связи • постоянное улучшение процесса
- 17. CAMS • Culture • AutomaQon • Measurement • Sharing
- 18. DevOps Manifesto • Набор ценностей • Реакция на недостаток коммуникаций • Создание отношений между dev и ops • Работа над продуктом, а не проектом • … hkp://bit.ly/devopsmanifesto
- 19. DevOps -‐ это не… • Сертификация • Роль • Инструменты • Прописанный процесс
- 20. Чем DevOps отличается от Agile? «Agile сыграл важную роль в разработке для восстановлению доверия у бизнеса, но он нечаянно оставил IT OperaQons позади. DevOps это способ восстановления доверия ко всей ИТ-‐организации в целом» Clyde Logue, основатель StreamStep
- 21. Чем DevOps отличается от ITIL и ITSM? DevOps добавляет в ITIL такие пункты как настройка сервисов, управление инцидентами и проблемами, поскольку цель не столько увеличение скорости выдачи нового функционала, сколько развертывания этого функционала в производстве без хаоса.
- 22. Каковы принципы DevOps? Три пути
- 23. Первый путь Производительность всей системы в целом, в отличие от производительности отдельного звена или отдела — это может быть как большое подразделение (например, разработка или ИТ отдел) так и отдельные люди (например, разработчик, системный администратор).
- 24. Второй путь Создании цикла обратной связи идущей справа налево. Целью практически любой инициативы по совершенствования процесса является сокращение и усиление обратной связи, чтобы необходимые поправки могли внедряться постоянно.
- 25. Третий путь Создании культуры, которая влияет на две вещи: постоянное экспериментирование, которое требует принятия рисков и извлечение уроков из успехов и неудач, а также понимание того, что повторения и практики являются предпосылкой к мастерству.
- 26. Понять систему Выстроить поток Организовать обратную связь Искать пути постоянного улучшения
- 27. Антипаттерны Devops • Длинные релизные циклы • Разногласия между Ops, Dev,Dba, Test, ... • Работает на Stage но не на producQon. • Долгая подготовка сред для поставки • Ручное обновление конфигов • Разнообразые OS, Middleware, … • Отсутствия понимания где и что работает • Ручное документирование
- 28. И еще… • Разделенные команды • Раздробленные системы • Dependency Hell • Ручные накаты баз данных • Гигантские Test Datasets • Тестирование руками • Релиз руками
- 29. И еще чуть-‐чуть • Неработающий деплой • Manual Rollbacks • Отсутствие версионирования • Code Freezes • …
- 30. 4 модели внедрения DevOps Модель 1: Углубление процессов разработки в поставку: это включает расширение непрерывной интеграции и выпуска в на боевые сервера, интеграция тестирования и информзащиты в рабочие процессы, что дает готовый к поставке код, настроенные среды, и так далее.
- 31. 4 модели внедрения DevOps Модель 2: Создание обратной связи от прода до разработки: включает создание полной хронологии событий в разработке и администрировании, с целью помощи в разрешении проблем, а так же предоставление доступа команде разработки к анализу проблем на проде, одновременно с созданием разработчиками сервисов самообслуживания, везде где это возможно, и создание информационных радиаторов, показывающих изменение в поведении системы при вносе изменений.
- 32. 4 модели внедрения DevOps Модель 3: Объединение разработки и администрирования: состоит во включении команды разработки в цепочку разрешения проблем, назначение разработчиков на разрешение проблем на проде, а так же взаимные тренинги между разработчиками и администраторами, чтобы уменьшить количество эскалаций.
- 33. 4 модели внедрения DevOps Модель 4: Включение ИТ команды в разработку: состоит во включении или тесной связью между IT и разработкой, создание многоэтапных пользовательских историй (включая развертывание, управление кодом в производстве и т.д.), и определение нефункциональных требования, которые могут быть использованы во всех проектах.
- 34.
- 35. Привлекайте админов к работе над продуктом как можно раньше
- 36.
- 37. То, что не может быть измерено, не может быть улучшено
- 38.
- 39.
- 40.
- 41. Враги Devops • Перекос мотивации • Неявные потребности • Non FuncQonal Requirements • SiloizaQon
- 42. Перекос мотивации • Senior management driven by total revenue • Sales is driven by compensaQon • Development is driven by delivery • Quality Assurance is driven by defects • OperaQons is driven by upQme
- 43. Non FuncQonal Requirements • Security • Backups • Availability and Performance • Upgrades • ConfiguraQon Management • Monitoring and Logging • Disaster Recovery
- 44. SiloizaQon • Security • Development • OperaQons • TesQng • Quality Assurance
- 45. Ключевые слова Devops • Agile Infrastructure • Infrastructure as Code • Done means Deployed • SDLC as Infrastructure
- 46.
- 47.
- 48.
- 49.
- 50.
- 51. Тренинги Киев, 29 – 30 августа Регистрация -‐ hkp://goo.gl/iX2wgs Тренер – Андрей Ребров
- 52.