Перевод статьи https://medium.com/devopslinks/the-15-point-devops-check-list-8cd2afb4a448
DevOps — это культура, которая требует некоторых наработок и нового видения, его общей целью является объединение людей и организаций вокруг уникальных целей.
Перечень DevOps, состоящий из 15 пунктов взят из технической книги (Jumpstart Up), которую я на самом деле пишу, чтобы предоставить практический справочник и руководство, основанное на опыте и ориентированное на приложение для проведения преобразования DevOps и Agile.
Чеклист DevOps не является ни статичным, ни уникальным, не существует манифеста, который бы описывал DevOps, но он должен быть адаптирован к потребностям организации, человеческому общению и другим конкретным критериям. Другими словами, этот чеклист может помочь вам приступить к внедрению культуры DevOps. Но не рассматривайте его как уникальный способ продолжить преобразование вашей организации.
Вы не обязаны полностью внедрять все эти пункты, но только начинайте с того, что вы можете делать, и что вам следует делать, и постоянно работайте над их совершенствованием.
Эти вопросы являются культурными, связанными с процессом или техническими. Во всех случаях что-то, чего я никогда не встречал или редко встречал в других перечнях – это надежность не только вашей живой среды, но и процессов, а надежность требует простоты. Простота не является элементом в следующем чеклисте, потому что она должна демонстрироваться в каждом из этих пунктов, поэтому не усложняйте.
Основным врагом надежности является сложность. “Geer et al”
«Простота является предпосылкой для надежности» Эдсгер В. Дейкстра
Кросс-функциональная команда
Кросс-функциональная команда — это группа людей с различным функциональными компетентностями (маркетинг, операции, разработка, QA, менеджеры по учетным записям и т. д.), работающих для достижения одних и тех же целей и проектов.
Группа людей различного происхождения и компетентностей собрана для более эффективного сотрудничества и более быстрого решения проблем.
Как говорится в Википедии: рост самонаправленных кросс-функциональных групп повлиял на процессы принятия решений и организационные структуры. Хотя теория управления любит утверждать, что каждый тип организационной структуры должен принимать стратегические, тактические и операционные решения, начали появляться новые методологии, которые лучше всего работают с командами.
В контексте DevOps команды dev и ops не должны жить в отдельных мирах. Каждая команда должна оказывать поддержку и давать советы, для лучшего использования навыков каждого.
Согласно некоторым исследованиям управления, таким как проведенным Питером Друкером по управлению по целями, кросс-функциональные команды имеют меньшую и не однонаправленную цель, что стимулирует производительность и способность работать с нечеткой логикой.
Культура общения и глобальное мышление
При совместной работе над одними и теми же продуктами общение связано с достижением лучших результатов и достижением важных целей. DevOps — это, в основном, культура общения и кросс-функционального сотрудничества. Отдельные лица и отделы могут говорить на разных профессиональных языках, что создает различные типы общения, как это происходит между разработчиками и операционными командами. У каждой команды свои собственные цели, инженеры-операторы стремятся к стабильности, в то время как разработчики склонны вносить изменения, которые в некоторых случаях могут повлиять на стабильность. Это не относится только к разработчикам и операционным инженерам, каждый отдел в среде, отличной от DevOps, имеет свои собственные цели и отдает почти 100% усилий и времени для ее достижения.
Очевидно, что с различными целями, разными обязанностями и разными профессиональными языками общение становится затруднительным. С этого момента отделы будут перекидывать ответственность за проблемы, которые они либо создают, либо с которыми сталкиваются.
Быть непреклонным в определении целей для каждого отдела — в большинстве случаев не очень хорошая идея. С общими целями можно сократить эту разницу между двумя или несколькими командами, когда цели, распределенные между отделами, и позволяют менеджерам, руководителям и всем членам команды знать о том, что есть общие цели.
Создание ведомственных и локальных целей создает проблему «это не моя работа», когда каждый отдел перекидывает ответственность друг на друга, в то время как установление общих и глобальных целей побуждает людей работать вместе.
Следующие хаки могут помочь вашей организации улучшить общение:
Мотивация через Gamification
Gamification — хороший способ сохранить мотивацию вашей команды, играючи.
В своей работе мы используем Hipchat, и я интегрировал несколько ботов в чате, но тот, который мне больше всего нравится, — бот Karma: каждый в моей команде вместо того, чтобы сказать «Спасибо», может дать одно или несколько очков кармы другому коллеге.
Это своего рода создание символической «меритократии». Фонд GNOME, Фонд Apache Software, Фонд Mozilla и Фонд документов являются примерами организаций (с открытым исходным кодом), которые официально заявляют, что они являются меритократиями.
Вы можете найти другие инструменты, которые могут помочь в геймификации рабочих пространств и повседневной профессиональной жизни, такой как Game Effective, для геймификации продаж, обслуживания клиентов и обучения сотрудников.
Смайлборд
В конце каждого рабочего дня каждый должен нарисовать изображение лица в одном из трех вариантов:
- Счастливое лицо
- Уставшее лицо
- Грустное лицо
Доска смайлов также называется «Календарь Niko-niko» (или «Календарь смайлов»). Это японское творение, где каждый член должен поместить смайлик в своем собственном расписании в конце дня, прежде чем покинуть офис. Таким образом, формируется представление о благополучии и мотивации каждого члена проекта.
Открытые и общие пространства
Правильно созданные открытые пространства являются ключом к ценным связям и сотрудничеству.
Чаты
Внутренние чат-приложения широко используются во многих организациях, обычно чаты предназначены для команды или проекта. Добавление чатов в таких инструментах, как Hipchat, Slack или любые их альтернативы, помогает командам общаться на нескольких повторяющихся событиях и быть ясным и осведомленными о:
- Внедрениях
- Инцидентах
- Создании
Разработчики берут на себя обязанности по серверу по контролю версий
В моей компании я даже создал ботов, которые постят ежедневные мотивационные цитаты, у нас есть также чаты, где мы говорим на темы, не связанные с работой.
Hackathons
Hackathon, hackfest, codefest или hackday — это событие, в котором люди, участвующие в разработке программного или аппаратного обеспечения, дизайне, UX, управлении проектами, интенсивно сотрудничают в проектах программного и аппаратного обеспечения. Hackathons, как правило, уделяют особое внимание технологии, теме или проекту, но некоторые Hackathons открыты, и участники имеют полную свободу. Hackathons — отличный способ построить общение и позволить людям из одной организации работать вместе и иметь одну и ту же цель. Внутренние Hackathons — это также способ, которым некоторые компании, такие как Netflix, Facebook, Google, Microsoft, Hewlett Packard, организуют продвижение инноваций нового продукта инженерным персоналом. Например, кнопка Facebook Like была задумана во время hackathon.
Тимбилдинг
Или помощь команде сделать ее более эффективной с точки зрения работоспособности, более сплоченной, последовательной в своих результатах и компетентной. Этот тип сопровождения особенно важен, когда профессиональная ситуация внутренне сложна во время процесса реорганизации или углубленных изменений в бизнесе или когда ситуация внешне сложна во время конкурентного давления или меняющегося рынка. Это помогает команде совместно создавать решение и развивать коллективный интеллект и автономию.
Игры
Игра — хороший способ создать хорошее коммуникативное поведение. Хорошим примером является симуляционная игра Kanban, имитирующая переменный рабочий процесс для компании SaaS. Игра GameCanban Board представляет собой физическую игру, предназначенную для обучения концепций и механиков Kanban для разработки программного обеспечения в классе или на рабочем месте.
Выходные, групповые прогулки, пятничные напитки
Культура, ориентированная на клиента
Культура, ориентированная на продукт, не будет работать в большинстве случаев, особенно если вы начинаете с MVP или даже больше и пытаетесь быть конкурентоспособными на рынке. Никто не знает, как продукт должен быть лучше самого клиента.
Для создания ориентированной на клиента культуры, вы должны:
- Не создавать лучший продукт, а создать лучшее решение для своего клиента.
- Перестать беспокоиться о создании новых продуктов или функций, а вместо этого искать новые способы удовлетворить потребности своих клиентов.- Нанимать подходящих людей и вознаграждать людей, имеющих глубокое понимание клиентов вместо вознаграждения новых функций или разработки продукта.
- Разделять нужды своих клиентов явным образом с вашими разработчи7ками и операционными инженерами. Будучи осведомленным о потребностях бизнеса и клиентов, это первый шаг к созданию ориентированной на клиента культуры.
На самом деле, сосредоточение внимания на клиентах — лучший способ объединить команды вокруг одних и тех же ценных целях, не создавая межотраслевую войну.
Цикл отзывов о DevOps также является хорошим способом обеспечения стабильности и масштабируемости ваших систем в одно и то же время, клиентам необходимо следующее: стабильность и масштабируемость.
Контроль источника и изменения
Согласно Википедии
Компонент управления конфигурацией программного обеспечения, контроль версий, также известный как контроль версий или контроль источника, — это управление изменениями в документах, компьютерных программах, больших веб-сайтах и других сборниках информации.
Контроль источника может иметь решающее значение для вашего успеха.
При разработке цифрового продукта важно предоставить разработчикам технический инструмент, эквивалентный инструментам управления проектами, но с чистой технической точки зрения. Контроль источника был создан для решения реальных проблем, с которыми разработчики сталкивались во время процесса кодирования, что позволяет им управлять:
- История изменения кода, чтобы упростить управление изменениями и возвращение к более старым версиям рабочего кода.
- Одновременное редактирование файлов, если несколько разработчиков работают над одним и тем же кодом.
- тегирование
- разветвление
- сращивание
Контроль версий не только для разработчиков, так как одна из лучших наработок в стартапах — это документация по версированию. Управление версиями документации поможет вам:
- Отслеживать инкрементные резервные копии и делать восстановление
- Записывать все изменения и возвращать документации в более раннюю версию
- Отслеживать соавторство и сотрудничество, и индивидуальные взносы
Большинство современных программных средств документации используют управление версиями как Atlassian Confluence или другое программное обеспечение с открытым исходным кодом, такое как wiki-программное обеспечение (MediaWiki, DocuWiki ..etc).
Инфраструктура как код
Управление инфраструктурой и предоставление ресурсов — это переход к следующей важной вещи: инфраструктура как код.
Инфраструктура как код (IaC) — это использование файлов определения и конфигурации для создания, запуска, остановки, удаления, прекращения и перезапуска виртуальных машин или машин из голого металла. При освоении IaC организации могут сократить затраты и время на управление инфраструктурой для большего сосредоточения на разработке продукта.
С ростом движения DevOps осуществление подхода непрерывной настройки автоматизации становится ключевым шагом в жизненном цикле продукта.
Я опубликовал статью на medium, где я объясняю, как инфраструктура как код может работать с помощью инструмента управления конфигурацией.
Обычная автоматизация
Философия DevOps может быть описана различными способами, но я встретил однажды хорошее определение DevOps с точки зрения автоматизации на Твиттере: «Использование вещей, которые вы можете программировать, и программирование тех вещей, которые вы используете».
Автоматизация в философии DevOps — это решение более быстрых задач для взаимодействия вещей и создания автоматизированных потоков. Практически все может быть сделано вручную, но для того, чтобы сосредоточиться на разработке продукта и создании непрерывных потоков (непрерывная интеграция, доставка, тестирование, развертывание ..etc) и циклов обратной связи, все начинается с автоматизации:
- Автоматизация инфраструктуры
- Автоматизация интеграции
- Автоматизация доставки
- Автоматизация отзывов
- Автоматизация масштабируемости
- Автоматизация поиска ошибок
- И т.д.
Непрерывные процессы зависят от уже автоматизированных задач
Конфигурация самообслуживания
Использование облачных технологий с программным обеспечением для управления конфигурацией позволяет автоматизировать предоставление инфраструктуры и услуг. Обычно инженеры-операторы после того, как выслушали разработчиков о необходимости разработки продукта, устанавливают и настраивают программное обеспечение на подобных серверах. Использование таких инструментов, как Chef, Puppet, Ansible или SaltStack, облачных инфраструктур, таких как AWS и Digital Ocean, системы управления версиями, такие как Github или Bitbucket, технологии контейнеров, такие как Docker, серверы непрерывной интеграции и развертывания, такие как Jenkins или Rundeck.
- Конфигурация системы всегда должна быть в службе / серверах управления версиями
- Разработчики должны уметь создавать системы с производственными конфигурациями и данными.
- Разработчики должны иметь доступ к задачам непрерывной интеграции для создания программного обеспечения и тестирования артефактов за короткий период: я предпочитаю работать с git-hooks, где автоматическая сборка запускается сразу же, когда разработчик вносит изменения на ветку разработки.
- В стадии зрелости разработчики могут внедрить изменения в производство: может быть, этого сложно достичь, в некоторых случаях предпочтительно, чтобы операционные инженеры развертывали продакшэн.
Автоматизированные сборки
С увеличением числа плагинов Jenkins автоматизация сборки становится проще. Примером веб-приложений пользуются автоматические инструменты сборки, такие как Ant с менеджерами пакетов, такими как npm и менеджерами зависимостей, такими как php-составитель.
Основными типами автоматизированных сборок являются:
- Востребованные автоматические сборки, когда пользователь запускает скрипт для запуска сборки, если это необходимо: этот процесс не полностью автоматизирован, а используется в тех случаях, когда запланированные и запущенные сборки сложны или бесполезны.
- Запланированные автоматические сборки, как в случае с серверами непрерывной интеграции (такими как Jenkins), которые работают в ночных сборках.
- Запущенные автоматизированные сборки, где сборки на сервере непрерывной интеграции запускаются сразу после фиксации в репозиторий git.
Непрерывная интеграция CI
Непрерывная интеграция использует автоматическую сборку для создания процесса, в котором сервер интеграции создает проект, если какие-либо изменения были сделаны или периодически. Этот процесс может также включать автоматические тесты и автоматическую доставку.
Непрерывная интеграция — важный кирпич в решении DevOps и слабое звено в процессе автоматизации, поскольку она расположена между разработкой и операциями, чтобы автоматизировать поток и оживить прохождение приложения от разработки до последующих операций.
Непрерывная доставка CD
Непрерывная доставка — это использование как непрерывной интеграции, так и автоматических сборок для доставки программного обеспечения другим командам как можно быстрее, в идеале после смены кода. Затем продукт поставляется на сервер артефактов или, по крайней мере, на FTP-сервер. В качестве примера, команды QA облакают доступ к последней поставке для выполнения своих тестов.
Если переход с этапа тестирования на этап развертывания продакшэна происходит автоматически, мы называем данный процесс непрерывным развертыванием.
Стабильная непрерывная доставка является признаком успеха для большой части движения DevOps. Если вы уже реализовали это в своем проекте DevOps, тогда вы освоите искусство DevOps.
Инкрементальное тестирование и опытно-ориентированная разработка
Тестирование опирается на концепции интеграционного тестирования, а инкрементное тестирование опирается на непрерывную интеграцию и доставку.
Инкрементное тестирование является непрерывным и повторяющимся по мере добавления новых и свежих функциональных возможностей.
Преимущество инкрементного подхода заключается в способности обнаружить новый дефект. Поскольку поиск ошибок на ранней стадии поможет вашей организации тратить меньше денег и стабилизировать производственные среды, инкрементное тестирование — одна из лучших практик в DevOps.
Могут быть приняты различные подходы к тестированию:
- Сверху вниз: Тестирование происходит сверху вниз, следуя за потоком управления. Например: начиная с GUI и заканчивая ядром программы.
- Снизу вверх: Тестирование происходит сверху вниз. Например: начиная с компонентов системы и заканчивая GUI.
- Функциональный инкремент: функции тестирования и функциональные возможности, описанные в функциональной спецификации
Разработка, основанная на испытаниях, является одной из концепций экстремального программирования (методология разработки программного обеспечения, которая призвана повысить качество и оперативность программного обеспечения и одну из гибких программных разработок).
TDD — одна из лучших практик, которые необходимо принять в культуре DevOps, она основана на инкрементальном тестировании и повторении очень короткого цикла разработки. Кент Бек, которому приписывают разработку или повторную технику, заявил в 2003 году, что TDD поощряет простые проекты и внушает уверенность.
Разработка, основанная на тестах, является первой концепцией, которую разработчики могут применять для улучшения и отладки кода или даже устаревшего кода, разработанного с использованием более старых методов и методологий.
Управление автоматизированным выпуском
Разработка продукта — это не только код. Продукт имеет весь жизненный цикл — от разработки, контроля версий, сборки, репозиториев и доставки артефактов, тестирования и принятия, предоставления серверов, конфигурации приложений для производственного развертывания. Этот цикл описывает управление выпуском, в то время как автоматизация является одним из столпов культуры DevOps, управление выпуском должно быть автоматизировано для улучшения бизнес-результатов.
Автоматизация управления выпуском опирается на автоматизацию всех его этапов, поэтому автоматизация выпуска требует создания стратегии непрерывной доставки.
Более короткие циклы развития и время выхода на рынок
Мотивация организации, ориентированной на клиента, с использованием упомянутых выше технологий, приведет к увеличению продолжительности цикла разработки и, в результате, к выходу на рынок.
Время выхода на рынок (ВВР) — это время, которое требуется от этапа разработки до развертывания и запуска продукта на производственных серверах. ВВР важно во всех отраслях, где продукты быстро устаревают, как это происходит в организации, работающей над веб-приложениями, продуктами SaaS или PaaS. Для того чтобы знать существующее и улучшать его, измерение времени выхода на рынок является хорошей практикой, одним из простейших подходов к его измерению является подсчет дней от концепции функции до развертывания стабильного выпуска, содержащего функцию к производству.
Гибкие методологии и пропагандисты культуры DevOps, работающие в режиме «спринта» разработки, в то время как рутинные задачи автоматизированы, интеграция и тесты непрерывны, спринт может занять от одной до двух недель и, следовательно, время выхода на рынок.
Ключевые показатели эффективности
Собственно, в моей работе я возглавляю преобразование DevOps. Иногда это может быть болезненно, но измерение вашего успеха мотивирует и вознаграждает. С первого месяца моей работы я определил основные проблемы и выбрал некоторые показатели, первое, что я сделал было измерение, после десяти месяцев (почти год) я начал собирать те же показатели для измерения. Хорошо, что показатели изменялись к лучшему:
- Время работы против простоя
- Коэффициент ошибок
- Ответная реакция
- Коэффициент отклонения
- Грузоподъемность
- Многие другие особые показатели
- И, конечно, время выхода на рынок.
Как было сказано выше, измерение времени выхода на рынок является хорошей практикой — это один из показателей, ориентированных на бизнес. Чтобы уменьшить длительность ВВР продукта, мы должны измерить фактическую, и то же аналогично для других улучшений
И, ключевые показатели эффективности (КП) являются ключевыми показателями эффективности, производительности и хорошего результата. Он может быть коллективным или личным и способствовать обмену глобальными целями, ведомственные KPI менее важны, чем глобальные KPI.
Ключевой показатель эффективности может соответствовать следующим целям:
- оценка
- диагностика
- связь
- Информация
- мотивация
- непрерывный прогресс
Индикаторы являются ключевой концепцией непрерывных улучшений, которые полагаются на:
Выбор ваших индикаторов, а не на выбор хороших показателей — это просто зависит от особенностей вашей организации, приоритетов и целей.
Автоматизация измерений: работа над спринтами улучшений — одна из лучших практик. Усовершенствования — это не этап или список задач, которые необходимо выполнить после внедрения продукта, а непрерывная работа, требующая непрерывного измерения, которое может быть автоматизировано. Хорошим примером является количество ошибок и ошибок, возникающих в вашей жизни или в ваших интеграционных средах. Я всегда думал, что экран с живыми измерениями KPI в open space — это гениальная идея.
Отзывы о DevOps
Для достижения инкрементного рабочего потока важна постоянная цепочка отзывов между командами разработки и разработки программного обеспечения. Отзыв — это описание текущего состояния программного обеспечения на протяжении всего его жизненного цикла.
Циклы отзывов — один из самых важных принципов DevOps, он может описывать цели методологии DevOps и Lean: непрерывные улучшения при одновременном отказе от процесса разработки и ИТ.
Этот отзыв может быть потоком в режиме реального времени в самых современных формах
Мониторинг, сбор и анализ журналов — это практика среди других, формирующих этот цикл обратной связи, и если вы привыкли к подобным методам, вы поймете, что речь идет об общении и ясности между двумя командами: dev и ops.
В стартапах изменение — это закон, поэтому высокие уровни развертывания часто приводят к сверхзаряду для ИТ-операций. Клайд Логей, основатель StreamStep, сказал: «Agile сыграл важную роль в развитии, восстанавливая доверие к бизнесу, но он непреднамеренно оставил ИТ-операции позади. DevOps — это способ для бизнеса восстановить доверие ко всей ИТ-организации в целом».
«В книге« Феникс-проект: роман об ИТ, DevOps и помощи вашей победе в бизнесе» описываются основополагающие принципы DevOps, описываются «Три пути», из которых выделяются принципы, из которых в свою очередь образовываются все шаблоны DevOps.
Системное мышление
Системное мышление подчеркивает, во-первых, эффективность всей системы, так что более узконаправленные цели будут считаться более важными, чем глобальные цели. Основное внимание уделяется всем потокам создания ценности, которые разрешены ИТ.
Увеличение цикла отзывов
Этот способ заключается в создании цикла отзывов для достижения улучшений при усилении циклов, что помогает понять потребности клиентов и отвечать на все внутренние потребности (как разработчики, так и системные администраторы ..и т.д.). Усиление цикла отзывов — это способ увеличить глобальную деградацию, вызванную локальными изменениями. Некоторые локальные изменения — это просто оптимизация, направленная на достижение индивидуальной или локальной цели, и увеличение количества отзывов в работе никогда не будет проводить дефект в нижестоящих рабочих центрах.
Культура непрерывных экспериментов и обучения
Этот путь связан с непрерывным экспериментированием, риском и непрерывным обучением. Повторение, таким образом, является предпосылкой для овладения, и эксперимент — это путь к улучшениям, который является повседневной работой. Отзыв может быть создан за более короткое время.
About The Author
Виктор Карабедянц
ИТ директор (CIO), руководитель нескольких DevOps команд. Профессиональный руководитель проектов по внедрению, поддержке ИТ систем и обслуживанию пользователей.