Книга: Руководство по DevOps

Оглавление книги

• Информация от издательства
• Предисловие к российскому изданию
• Введение
• «Ага!»
• Джин Ким
• Джез Хамбл
• Патрик Дюбуа
• Джон Уиллис
• «Ага!» еще несколько раз
• Предисловие
• Вступление. Как будет выглядеть мир, если разработка и эксплуатация пойдут по принципу DevOps
• Проблема: кое-что в вашей организации должно быть улучшено (иначе вы не стали бы читать эту книгу)
• Коренной, хронический конфликт
• Нисходящая спираль: драма в трех актах
• Почему нисходящая спираль встречается везде
• Издержки в человеческих и экономических ресурсах
• Этическая сторона DevOps: лучший путь
• Разрываем нисходящую спираль, используя DevOps
• Ценность DevOps для бизнеса
• DevOps помогает увеличивать продуктивность разработчиков
• Универсальность решения
• Руководство по DevOps: краткий обзор
• Часть I. «Три пути»
• Введение
• Краткая история
• Принципы бережливого производства
• Agile-манифест
• Agile-инфраструктура и движение Velocity
• Непрерывная поставка
• Ката компании Toyota
• Глава 1. Agile, непрерывная поставка и «три пути»
• Производственный поток ценности
• Технологический поток ценности
• Фокус на времени развертывания
• Определения: «время выполнения заказа» и «время производства»
• Обычный сценарий: развертывание требует месяцев
• Идеал DevOps — развертывание за минуты
• Наблюдать за %C/A в качестве оценки необходимости доработок
• «Три пути»: принципы, лежащие в основе DevOps
• Заключение
• Глава 2. Первый путь: принципы потока
• Сделать работу прозрачной
• Ограничить количество незавершенной работы (НзП)
• Уменьшить размер заданий
• Уменьшить количество случаев передачи работы
• Постоянно выявлять затруднения и стремиться их разрешать
• Исключить затруднения и потери в потоке создания ценности
• Заключение
• Глава 3. Второй путь: принципы обратной связи
• Безопасная работа в сложных системах
• Видеть проблемы сразу после появления
• Объединиться вокруг проблемы и решить ее, добывая новое знание
• Продолжайте, улучшая качество кода
• Включить оптимизацию на рабочих местах нижнего уровня
• Заключение
• Глава 4. Третий путь: принципы непрерывного обучения и экспериментирования
• Создание условий для формирования культуры организационного обучения и безопасности
• Взять за правило улучшение повседневной работы
• Преобразовать локальные открытия в глобальные улучшения
• Встроить шаблоны устойчивости в повседневную работу
• Лидеры укрепляют культуру обучения
• Заключение
• Заключение к части I
• Ката компании Toyota
• Часть II. Откуда начать
• Введение
• Глава 5. Как выбрать стартовый поток создания ценности
• Сервисы чистые и нечистые
• Рассматривая и системы записей, и системы совместной работы
• Начиная с сочувствующих и новаторских групп
• Распространение DevOps на всю организацию
• Заключение
• Глава 6. Основные сведения о работе в потоке создания ценности, превращении его в прозрачный и расширении на всю организацию
• Определение всех команд, обеспечивающих поток создания ценности
• Формирование карты потока создания ценности: видеть выполняемую работу
• Создание команды преобразований
• Договориться об общей цели
• Продолжать улучшения, планируя на короткие сроки
• Резервируем 20 % времени для реализации требований, не связанных с функциональностью, и для выплаты технического долга
• Практический пример
• Операция InVersion в компании LinkedIn (2011 г.)
• Увеличить прозрачность работы
• Используйте инструменты для закрепления необходимого поведения
• Заключение
• Глава 7. Как проектировать организацию и ее архитектуру, не забывая о законе Конвея
• Архетипы организационной структуры
• Проблемы часто бывают вызваны чрезмерно функциональной ориентацией («оптимизацией затрат»)
• Создать условия для команд, ориентированных на рынок («оптимизация скорости»)
• Создание функционально ориентированной работы
• Тестирование, эксплуатация и безопасность — повседневная работа каждого
• Каждый член команды может стать универсалом
• Финансируйте не проекты, а сервисы и продукты
• Устанавливайте границы между командами в соответствии с законом Конвея
• Создавайте слабосвязанные архитектуры, чтобы обеспечить продуктивность и безопасность труда разработчиков
• Сохраняйте размеры команд небольшими (правило «команда на две пиццы»)
• Практический пример
• Программа API Enablement компании Target (2015 г.)
• Заключение
• Глава 8. Как получить лучшие результаты, интегрируя эксплуатацию в повседневную деятельность разработчиков
• Создание общедоступных инструментов для повышения эффективности разработчиков
• Включайте инженеров эксплуатации в команды разработки сервисов
• Назначение «контактов с эксплуатацией» в каждую команду разработки сервисов
• Введите инженера эксплуатации в рабочие процедуры команды разработчиков
• Приглашайте инженеров эксплуатации на собрания разработчиков
• Приглашайте инженеров эксплуатации на ретроспективные обзоры
• Сделать работу эксплуатации прозрачной на общих досках канбан
• Заключение
• Заключение ко второй части
• Часть III. Технические практики потоков создания ценности
• Введение
• Глава 9. Создание основы конвейера внедрения
• Обеспечить создание сред по требованию для разработчиков, тестировщиков и эксплуатации
• Создайте единый репозиторий для всей системы
• Сделать так, чтобы инфраструктуру было проще построить заново, чем восстанавливать
• Измените для разработчиков определение состояния «выполнено», чтобы оно включало выполнение в среде, приближенной к производственной
• Заключение
• Глава 10. Быстрое и надежное автоматизированное тестирование
• Непрерывные сборка, тестирование и интеграция кода и среды
• Создайте комплекс быстрой и надежной автоматизированной тестовой проверки
• Обнаружение ошибок с помощью автоматизированного тестирования на самых ранних этапах
• Идеальное и неидеальное автоматизированное тестирование
• Обеспечьте быстрое выполнение тестов (если необходимо — параллельное)
• Пишите автоматизированные тесты до того, как начнете писать код («разработка через тестирование»)
• Автоматизируйте как можно больше тестов
• Встраиваем тесты производительности в программу тестирования
• Включайте проверку нефункциональных требований в программу тестирования
• Дергайте за шнур-андон, если конвейер развертывания поврежден
• Почему нужно дергать за шнур-андон
• Заключение
• Глава 11. Запустить и практиковать непрерывную интеграцию
• Мелкосерийная разработка, и что происходит, когда мы редко фиксируем код в основной ветке
• Внедрить методы разработки на базе основной ветки
• Практический пример
• Непрерывная интеграция в компании Bazaarvoice (2012 г.)
• Заключение
• Глава 12. Автоматизация и запуск релизов с низким уровнем риска
• Количество разработчиков в неделю, развертывающих свой код
• Автоматизируем процесс развертывания
• Практический пример
• Ежедневное развертывание в компании CSG International (2013 г.)
• Включите автоматизированное самообслуживание развертываний
• Интегрируйте развертывание кода в конвейер развертывания
• Практический пример
• Самообслуживаемое развертывание разработчиками в компании Etsy — пример непрерывного развертывания (2014 г.)
• Отделить развертывания от релизов
• Шаблоны релиза на основе среды
• Шаблон Blue-Green развертывания
• Управление сменой баз данных
• Практический пример
• Blue-Green развертывание для системы торговых точек компании Dixons Retail (2008 г.)
• Шаблоны канареечных релизов и cluster immune systems
• Шаблоны релиза на основе приложений обеспечивают более безопасный релиз
• Реализация переключателей функциональности
• Выполняйте теневые запуски
• Практический пример
• Теневой запуск чата Facebook (2008 г.)
• Обзор непрерывной доставки и непрерывного развертывания на практике
• Заключение
• Глава 13. Архитектура низкорисковых релизов
• Архитектура, обеспечивающая производительность, тестируемость и безопасность
• Облачное хранилище данных компании Google
• Архитектурные архетипы: монолитный или микросервисы
• Практический пример
• Эволюционная архитектура в компании Amazon (2002 г.)
• Используем шаблон «удушающих приложений», чтобы безопасно развивать архитектуру нашей организации
• Практический пример
• Шаблон удушения в программе Blackboard Learn (2011 г.)
• Заключение
• Заключение к третьей части
• Часть IV. Второй путь: методики обратной связи
• Введение
• Глава 14. Создайте телеметрию, позволяющую замечать проблемы и решать их
• Создайте централизованную телеметрическую инфраструктуру
• Создайте телеметрию логирования приложений, полезную на этапе эксплуатации
• Используйте телеметрию в решении проблем
• Обеспечьте сбор показателей эксплуатации в процессе ежедневной работы
• Количество входов в систему
• Практический пример
• Создание показателей самообслуживания в компании LinkedIn (2011 г.)
• Найдите и устраните пробелы в системе вашей телеметрии
• Приложения и бизнес-метрики
• Сообщения на форуме
• Показатели инфраструктуры
• Наложение новой информации на старые показатели
• Заключение
• Глава 15. Анализируйте телеметрию, чтобы лучше предсказывать проблемы и добиваться поставленных целей
• Используйте средние и стандартные отклонения для обнаружения потенциальных проблем
• Создайте инструменты фиксации и оповещения о нежелательных событиях
• Практический пример
• Автоматическая масштабируемость ресурсов, Netflix (2012 г.)
• Использование методик выявления аномалий
• Практический пример
• Продвинутое выявление аномалий (2014 г.)
• Заключение
• Глава 16. Настройте обратную связь, чтобы разработчики и инженеры эксплуатации могли безопасно разворачивать код
• Используйте телеметрию для более безопасного развертывания
• Разработчики дежурят наравне с сотрудниками эксплуатации
• Убедитесь, что разработчики следят за низкоуровневым кодом
• Пусть поначалу разработчики сами сопровождают свой продукт
• Практический пример
• Обзор готовности к релизу и передаче продукта в компании Google (2010 г.)
• Заключение
• Глава 17. Встройте основанную на гипотезах разработку и A/B-тестирование в свою повседневную работу
• Краткая история A/B-тестирования
• Интегрирование A/B-тестирования в тестирование компонентов функциональности
• Интегрируйте A/B-тестирование в релизы
• Интеграция A/B-тестирования в планирование функциональности
• Практический пример
• Удвоение роста доходов благодаря экспериментированию с циклом быстрых релизов, Yahoo! Answers (2010 г.)
• Заключение
• Глава 18. Создайте процессы проверки и координации для улучшения качества текущей работы
• Опасность процесса согласования изменений
• Потенциальные опасности чрезмерного контроля над изменениями
• Производительность в IT
• Рецензии коллег vs Получение разрешений
• Обеспечьте условия для координации и планирования изменений
• Введите практику рецензирования изменений
• Практический пример
• Потенциальные опасности тестирования преимущественно вручную и заморозки изменений
• Введите практику парного программирования, чтобы улучшить качество изменений
• Практический пример
• Замена неэффективного рецензирования кода парным программированием в организации Pivotal Labs (2011 г.)
• Оценка эффективности pull request процессов[139]
• Бесстрашно избавляйтесь от бюрократических процессов
• Заключение
• Заключение части IV
• Создание показателей самообслуживания в компании LinkedIn (2011 г.)
• Найдите и устраните пробелы в системе вашей телеметрии
• Приложения и бизнес-метрики
• Сообщения на форуме
• Показатели инфраструктуры
• Наложение новой информации на старые показатели
• Заключение
• Часть V. Третий путь: методики непрерывного обучения и экспериментирования
• Введение
• Глава 19. Внедрите обучение в повседневную работу
• Создайте культуру беспристрастности и обучения
• Запланируйте встречи для разбора ошибок без поиска виноватых
• Распространяйте информацию с разбора ошибок как можно шире
• Уменьшите стандартные отклонения, чтобы улавливать слабые сигналы о возможных сбоях
• Переопределите понятие ошибки и поощряйте взвешенный риск
• Устраивайте намеренные сбои, чтобы укрепить адаптивность и улучшить обучение
• Устраивайте Game Days, чтобы репетировать неполадки
• Заключение
• Глава 20. Преобразуйте локальные открытия в глобальные улучшения
• Используйте чаты и чат-ботов, чтобы автоматизировать и сохранять знания компании
• Автоматизируйте типовые процессы в ПО для многократного использования
• Создайте единый общедоступный репозиторий для всей организации
• Распространяйте знания, используя автоматизированные тесты как документацию и механизм обмена опытом
• Определите четкие нефункциональные требования, чтобы при проектировании учитывались пожелания эксплуатации
• Встройте пожелания команд эксплуатации в процесс разработки
• Используйте технологии, работающие на достижение целей компании
• Практический пример
• Стандартизация нового стека технологий в Etsy (2010 г.)
• Заключение
• Глава 21. Выделите время для обучения и улучшений
• Создайте ритуалы для погашения технического долга
• Позвольте каждому учить и учиться
• Делитесь опытом с DevOps-конференций
• Практический пример
• Внутренние технологические конференции в Nationwide Insurance, Capital One и Target (2014 г.)
• Используйте наставничество и внутреннее консультирование для распространения практик
• Заключение
• Заключение к части V
• Часть VI. Методики интегрирования информационной безопасности, управления изменениями и контроля над соответствием нормам и требованиям
• Введение
• Глава 22. Защита информации как часть повседневной работы всех сотрудников компании
• Приглашайте инженеров службы безопасности на презентации промежуточных этапов создания продуктов
• Вовлекайте инженеров безопасности в поиск дефектов и приглашайте их на совещания по разбору ошибок и сбоев
• Встройте профилактические средства контроля безопасности в общие репозитории и сервисы
• Встройте меры безопасности в конвейер развертывания
• Обеспечьте безопасность приложений
• Практический пример
• Статическое тестирование безопасности в компании Twitter (2009 г.)
• Проконтролируйте безопасность системы поставок программного обеспечения
• Обеспечьте безопасность программной среды
• Практический пример
• Автоматизация проверок на соответствие требованиям с помощью Compliance Masonry, сделанное группой 18F для федерального правительства
• Дополните информационную безопасность телеметрией
• Создайте телеметрию защиты данных в приложениях
• Создайте телеметрию защиты данных в своих средах
• Практический пример
• Оснащение сред инструментами слежения в компании Etsy (2010 г.)
• Защитите конвейер развертывания
• Заключение
• Глава 23. Безопасность конвейера развертывания
• Встройте цели защиты данных и выполнения требований в процесс одобрения изменений
• Переместите большинство низкорисковых правок в категорию стандартных изменений
• Что делать с изменениями из категории нормальных
• Практический пример
• Автоматизированные изменения инфраструктуры как стандартные изменения в компании Salesforce.com (2012 г.)
• Уменьшите зависимость от разделения обязанностей
• Практический пример
• Стандарты безопасности PCI и поучительная история о разделении обязанностей в компании Etsy (2014 г.)
• Храните документацию для аудиторов и проверяющих органов
• Практический пример
• Доказательства соблюдения требований в регулируемых средах (2015 г.)
• Практический пример
• Эксплуатационная телеметрия в системах управления банкоматами
• Заключение
• Заключение части VI
• Призыв к действию. Заключение
• Дополнительные материалы
• Приложения
• Свод правил DevOps
• Бережливое производство
• Гибкая разработка
• Конференции Velocity
• Гибкая инфраструктура
• Непрерывная поставка
• Тойота Ката
• Бережливый стартап
• Lean UX
• Rugged computing
• Теория ограничений и ключевых хронических конфликтов
• Нисходящая спираль в виде таблицы
• Опасности передачи ответственности и очередей
• Время ожидания = (% Занят) / (% Свободен)
• Мифы об индустриальной безопасности
• Шнур-андон компании Toyota
• Коммерческое готовое программное обеспечение
• Совещания для послеаварийной ретроспективы
• Обезьянья армия
• Transperant Uptime
• Дополнительная литература
• МИФ Бизнес
• Над книгой работали
• Сноски из книги
• Содержание книги
• Популярные страницы