Контрольный список DevOps

  • Статья

DevOps — это интеграция операций разработки, контроля качества и ИТ-операций в единую среду и набор параметров для предоставления программного обеспечения. Используйте этот контрольный список в качестве отправной точки для оценки языка и региональных параметров, а также процессов DevOps.

Культура

Обеспечьте выравнивание бизнеса между организациями и командами. Конфликты за ресурсы, цели и приоритеты внутри организации могут представлять риски для успешного выполнения операций. Убедитесь, что рабочие группы, разработки и операции согласованы.

Убедитесь, что ваша команда понимает жизненный цикл программного обеспечения. Ваша команда должна понять общий жизненный цикл ваших приложений и где каждое приложение находится в этом жизненном цикле. Наличие этой информации помогает всем участникам команды знать, что они должны делать сейчас, и что они должны планировать и подготовиться в будущем.

Сократите время цикла. Цель свести к минимуму время, необходимое для перехода от идей к пригодного для использования программного обеспечения. Ограничьте размер и область отдельных выпусков, чтобы поддерживать тестовую нагрузку на низком уровне. Автоматизация процессов сборки, тестирования, конфигурации и развертывания по возможности. Очистите все препятствия для взаимодействия между разработчиками, а также между разработчиками и рабочими группами.

Проанализируйте и оптимизируйте процессы. Процессы и процедуры (и автоматические, и ручные) никогда не являются окончательными. Установите регулярные проверки текущих рабочих процессов, процедур и документации с целью их непрерывного усовершенствования.

Выполняйте предварительное планирование. Заранее готовьтесь к сбою. Выполняйте процессы для быстрого выявления проблем при их возникновении, перерастания проблем в правильные члены команды для устранения и подтверждения их разрешения.

Учитесь на ошибках. Сбои неизбежны, однако важно учиться на ошибках, чтобы не повторять их. Если происходит операционный сбой, изучите проблему, задокументируйте причину и решение и поделитесь любыми уроками, которые вы узнаете. По возможности обновляйте свои процессы создания, чтобы автоматически обнаруживать подобные сбои в будущем.

Оптимизируйте скорость и сбор данных. Каждое запланированное улучшение — это гипотеза. Работайте в наименьших увеличениях, которые возможны. Считайте новые идеи экспериментами. Инструментируйте эксперименты, чтобы можно было собирать рабочие данные для оценки эффективности эксперимента. Будьте готовы к быстрому сбою, если гипотеза неправильная.

Выделите время для обучения. Неудачи и успехи предоставляют возможности для обучения. Прежде чем перейти к новым проектам, разрешите время собирать важные уроки, и убедитесь, что ваша команда поглощает эти уроки. Кроме того, предоставьте команде время для создания навыков, экспериментов и изучения новых инструментов и методов.

Документируйте операции. Документируйте все средства, процессы и автоматизированные задачи с тем же уровнем качества, что и код продукта. Задокументируйте текущую структуру и архитектуру всех систем, которые вы поддерживаете, а также процессы восстановления и другие процедуры обслуживания. Сосредоточьтесь на шагах, которые вы на самом деле делаете, а не теоретически оптимальных процессах. Регулярно просматривайте и обновляйте документацию. Для кода обязательно включите значимые комментарии, особенно в общедоступных API. По возможности используйте средства для автоматического создания документации по коду.

Делитесь знаниями. Документация полезна, только если пользователи знают, что она имеется, и могут ее найти. Упорядочение документации и упрощение обнаружения. Будьте изобретательны: используйте короткие презентации (неофициальные презентации), видеоролики или информационные бюллетени для обмена знаниями.

Разработка

Предоставьте разработчикам среду, максимально приближенную к рабочей. Если среды разработки и тестирования не соответствуют рабочей среде, трудно проверить и диагностировать проблемы. Не закрывайте среды разработки и тестирования как можно ближе к рабочей среде. Убедитесь, что тестовые данные согласованы с данными, которые вы используете в рабочей среде, даже если это примеры данных, а не реальные рабочие данные (по соображениям конфиденциальности или соответствия требованиям). Запланируйте создание примера тестовых данных и сделайте его анонимным.

Убедитесь, что все авторизованные члены группы могут подготавливать инфраструктуру и развертывать приложения. Настройка рабочих ресурсов и развертывание приложения не должно включать сложные задачи вручную или подробные технические знания системы. Любой пользователь с правильными разрешениями должен иметь возможность создавать или развертывать рабочие ресурсы, не перейдя в свою группу операций.

Эта рекомендация не означает, что любой пользователь может отправлять динамические обновления в рабочее развертывание. Речь о снижении трений для разработки и групп качества обслуживания для создания рабочих сред.

Инструментирование каждого приложения для анализа. Чтобы понять работоспособность приложений, необходимо знать, как они выполняются и возникают ли ошибки или проблемы. Всегда включать инструментирование в качестве требования к проектированию и сборку инструментирования в каждое приложение с самого начала. Инструментирование должно включать ведение журнала событий для анализа первопричин, а также телеметрию и метрики для мониторинга работоспособности и использования каждого приложения.

Следите за техническими компромиссами. Многие проекты определяют приоритеты расписания выпуска по сравнению с качеством кода на одну степень или другую. Всегда документировать при выполнении ярлыков или других неоптимальных реализаций и запланировать время, чтобы вернуться к этим проблемам.

Рассмотрите возможность отправки обновлений непосредственно в рабочую среду. Чтобы сократить общее время цикла выпуска, рассмотрите возможность принудительного отправки правильно проверенных фиксаций кода непосредственно в рабочую среду. Используйте переключатели функций, чтобы управлять тем, какие функции вы включаете. Затем вы можете быстро перейти от разработки к выпуску с помощью переключателей для включения или отключения функций. Переключатели также полезны при выполнении тестов, таких как канареарные выпуски, где развертывается определенная функция в подмножестве рабочей среды.

Тестирование

Автоматизируйте тестирование. Тестирование программного обеспечения вручную занимает много времени и подвержено ошибкам. Автоматизация распространенных задач тестирования и интеграция тестов в процессы сборки. Автоматизированное тестирование гарантирует согласованность и воспроизводимость протестированного кода. При выполнении интегрированных тестов пользовательского интерфейса также используйте автоматизированное средство. Azure предлагает ресурсы для разработки и тестирования, которые могут помочь в настройке и запуске тестов. Дополнительные сведения см. в статье "Разработка и тестирование в Azure".

Выполняйте тестирование на наличие сбоев. Если система не может подключиться к службе, система должна реагировать корректно. И когда служба доступна снова, система должна восстановиться. Сделайте тестирование путем внедрения ошибки стандартной частью проверки в тестовых и промежуточных средах. Когда процесс тестирования и методы станут отлаженными, рассмотрите возможность выполнения этих тестов в рабочей среде.

Выполняйте тестирование в рабочей среде. Процесс выпуска не заканчивается развертыванием в рабочей среде. У вас должны быть предусмотрены тесты, гарантирующие, что развернутый код работает должным образом. Для развертываний, которые редко обновляются, запланируйте рабочее тестирование как обычную часть обслуживания.

Автоматизируйте тестирование производительности, чтобы раньше идентифицировать проблемы производительности. Влияние серьезной проблемы производительности может быть столь серьезным, как ошибка в коде. Хотя автоматизированные функциональные тесты могут предотвратить ошибки приложения, эти тесты могут не обнаруживать проблемы с производительностью. Определите приемлемые показатели производительности для таких метрик, как задержка, время загрузки и потребление ресурсов. Включите автоматические тесты производительности в конвейер выпуска, чтобы убедиться, что приложение соответствует этим целям.

Выполните тестирование емкости. Приложение может работать нормально в условиях тестирования, а затем могут появиться проблемы в рабочей среде из-за ограничений масштаба или ресурсов. Всегда определяйте максимальные ожидаемые ограничения емкости и использования. Протестируйте, чтобы убедиться, что приложение может обрабатывать эти ограничения, но также проверить, что происходит при превышении этих ограничений. Выполнять тестирование емкости через регулярные интервалы.

После первоначального выпуска следует выполнять тесты производительности и емкости при обновлении рабочего кода. Используйте исторические данные для точной настройки тестов и определения типов тестов, которые необходимо выполнить.

Выполняйте автоматические тесты на проникновение в систему безопасности. Обеспечение безопасности приложения так же важно, как тестирование любых других функций. Сделайте автоматическое тестирование на проникновение стандартной частью процесса сборки и развертывания. Планируйте регулярные тесты на проникновение и сканирование уязвимостей в развернутых приложениях, а также мониторинг открытых портов, конечных точек и атак. Автоматическое тестирование не устраняет необходимость в подробных проверках безопасности через регулярные промежутки времени.

Выполняйте автоматическое тестирование непрерывности бизнес-процессов. Разработайте тестирование непрерывности бизнес-процессов в больших масштабах, включая восстановление резервной копии и отработку отказа. Настройте автоматизированные процессы для регулярного выполнения этих тестов.

Выпуск

Автоматизируйте развертывания. Автоматизация обеспечивает множество преимуществ, в том числе:

  • Включение более быстрых и более надежных развертываний.
  • Обеспечение согласованности развертываний в любой поддерживаемой среде, включая тестирование, промежуточное развертывание и рабочую среду.
  • Удаление риска человеческой ошибки, в которую могут ввести развертывания вручную.
  • Упрощая планирование выпусков в удобное время, что позволяет свести к минимуму любые последствия потенциального простоя.

Автоматизируйте процесс развертывания каждого приложения в тестовых, промежуточных и рабочих средах. У вас должны быть системы для выявления проблем во время развертывания, а также автоматизированный способа наката исправлений или отката изменений.

Используйте непрерывную интеграцию. Непрерывная интеграция (CI) — это практика объединения всего кода разработчика в центральную базу кода по регулярному расписанию, а затем автоматическое выполнение стандартных процессов сборки и тестирования. CI гарантирует, что вся команда может работать над базой кода одновременно без конфликтов. CI также помогает найти дефекты кода как можно раньше. Предпочтительно, процесс CI должен выполняться каждый раз, когда вы фиксируете или проверка в коде. Он должен выполняться по крайней мере один раз в день.

Попробуйте внедрить модель разработки на основе магистралей. В этой модели разработчики фиксируют одну ветвь (магистраль). Существует требование, которое фиксации никогда не прерывают сборку. Эта модель упрощает ci, так как все функции работают в магистрали и разрешают любые конфликт слияния при каждой фиксации.

Рассмотрите возможность использования непрерывной поставки. Непрерывная поставка — это метод обеспечения постоянной готовности кода к развертыванию путем автоматического создания, тестирования и развертывания кода в рабочих средах. Добавление CD для создания полного конвейера CI/CD помогает обнаруживать дефекты кода как можно скорее. Он также гарантирует, что вы можете освободить правильно проверенные обновления в течение короткого времени.

Непрерывное развертывание — это процесс, который автоматически принимает все обновления, передаваемые через конвейер CI/CD, и развертывает их в рабочей среде. Для непрерывного развертывания требуется надежное автоматическое тестирование и заблаговременного планирование процессов. Это может оказаться неприемлемым для части групп.

Внесите небольшие добавочные изменения. Крупные изменения кода имеют больший потенциал для внедрения ошибок, чем небольшие. По возможности вносите небольшие изменения. Это ограничивает потенциальные последствия каждого изменения и упрощает задачу понимания и отладки проблем.

Управляйте доступностью изменений. Убедитесь, что вы управляете тем, когда обновления становятся видимыми для конечных пользователей. Рекомендуется использовать переключатели функций для управления включением функций для конечных пользователей.

Реализуйте стратегии управления выпусками, чтобы снизить риск при развертывании. Развертывание обновления приложения в рабочую среду всегда влечет за собой определенный риск. Чтобы свести его к минимуму, используйте стратегии, такие как ранние выпуски или развертывания по схеме Blue-Green, для развертывания обновлений для группы пользователей. Убедитесь, что каждое обновление работает должным образом, а затем разверните каждое обновление в остальной части системы.

Документируйте все изменения. Незначительные изменения и изменения конфигурации могут стать источником неточностей и конфликтов версий. Всегда храните отчет о любых изменениях, независимо от их размера. Регистрируйте все изменения, включая примененные исправления, изменения политики и изменения конфигурации. Запись изменений должна быть видна всей команде. Но не включать конфиденциальные данные в эти журналы. Например, запишите обновленные учетные данные и кто сделал это изменение, но не записывайте обновленные учетные данные.

Рассмотрите возможность использования неизменяемой инфраструктуры. Неизменяемая инфраструктура основана на принципе, который не следует изменять инфраструктуру после развертывания в рабочей среде. В противном случае может произойти ситуация, в которой были применены ситуативные изменения, затрудняющие точное определение того, что изменилось. Неизменяемая инфраструктура выполняется путем замены целых серверов в качестве части любого нового развертывания. С помощью этого подхода можно протестировать и развернуть код и среду размещения в виде блока. После развертывания компоненты инфраструктуры не изменяются до следующего цикла сборки и развертывания.

Наблюдение

Сделайте системы отслеживаемыми. Ваша группа операций всегда должна иметь четкое представление о работоспособности и состоянии системы или службы. Настройте внешние конечные точки работоспособности для отслеживания состояния и приложений кода для инструментирования метрик операций. Используйте общую согласованную схему, которая позволит сопоставлять события в различных системах. Стандартный способ отслеживания работоспособности и состояния ресурсов Azure — использовать Диагностика Azure и приложение Аналитика. Azure Monitor также обеспечивает централизованный мониторинг и управление для облачных или гибридных решений.

Вычисляйте и коррелируйте журналы и метрики. Правильно инструментированная система телеметрии обеспечит большое количество необработанных данных производительности и журналов событий. Убедитесь, что системные процессы и коррелируют данные телеметрии и журналов быстро, чтобы персонал операций всегда был актуальной картиной работоспособности системы. Упорядочение и отображение данных, чтобы иметь согласованное представление о проблемах и видеть, когда события связаны друг с другом.

Ознакомьтесь с политикой хранения организации, чтобы узнать, как обрабатывать данные и сколько времени хранить данные.

Реализуйте автоматические оповещения и уведомления. Настройте средства мониторинга, такие как Монитор , для обнаружения шаблонов или условий, указывающих на потенциальные или текущие проблемы. Отправка оповещений участникам группы, которые могут устранить проблемы. Настройте оповещения таким образом, чтобы избежать ложных срабатываний.

Отслеживайте срок действия ресурсов. Некоторые ресурсы и активы, такие как сертификаты, имеют ограниченный срок действия. Обязательно отслеживайте ресурсы, срок действия которых истекает, когда он истекает и какие службы или возможности зависят от этих ресурсов. Используйте автоматизированные процессы для мониторинга этих ресурсов. Уведомите свою группу операций до истечения срока действия актива и обострите ситуацию, если срок действия угрожает нарушить работу приложений.

Управление

Автоматизируйте задачи операций. Обработка повторяющихся операций вручную сопровождается частыми ошибками. По возможности автоматизируйте эти задачи, чтобы обеспечить согласованное выполнение и высокое качество. Используйте управление версиями для кода версии, реализующего автоматизацию. Как и в любом другом коде, протестируйте средства автоматизации.

Примените подход "инфраструктура как код" при подготовке. Свести к минимуму объем конфигурации вручную, необходимой для подготовки ресурсов. Вместо этого используйте скрипты и шаблоны Azure Resource Manager. Сохраняйте скрипты и шаблоны в системе управления версиями, как и любой другой код, который вы поддерживаете.

Рассмотрите возможность использования контейнеров. Контейнеры предоставляют стандартный интерфейс на основе пакета для развертывания приложений. При использовании контейнеров вы развертываете приложение с помощью автономных пакетов, включающих любое программное обеспечение, зависимости и файлы, необходимые для запуска приложения. Эта практика значительно упрощает процесс развертывания.

Контейнеры также создают слой абстракции между приложением и базовой операционной системой, которая обеспечивает согласованность между средами. Эта абстракция может также изолировать контейнер от других процессов или приложений, выполняемых на узле.

Реализуйте механизмы устойчивости и самовосстановления. Устойчивость — это способность приложения восстанавливаться после сбоев. Стратегии обеспечения устойчивости включают повторы в случае временных сбоев и выполнение отработки отказа во вторичный экземпляр или даже в другой регион. Дополнительные сведения см. в статье "Проектирование надежных приложений Azure". Инструментируйте приложения для немедленного сообщения о проблемах, чтобы управлять сбоями или другими системными сбоями.

Создайте руководство по эксплуатации. Руководство по операциям или runbook документирует процедуры и сведения об управлении, необходимые для обслуживания системы персоналом операций. Кроме того, документируются любые сценарии операций и планы по устранению рисков, используемые во время сбоя или другого прерывания работы службы. Создайте эту документацию во время процесса разработки и оставьте ее актуальной. Эти ресурсы рассматриваются как живые документы, которые необходимо регулярно просматривать, тестировать и улучшать.

Предоставление общего доступа к документации — критически важно. Поощряйте членов команды вносить свой вклад и делиться знаниями. У всей команды должен быть доступ к документам. Упростите этот процесс для всей команды, чтобы помочь обеспечить обновление документов.

Документируйте процедуры вызова. Обязательно задокументируйте обязанности по вызову, расписания и процедуры, а также поделитесь ими со всеми участниками команды. Всегда обновляйте эти сведения.

Документируйте процедуры эскалации для сторонних зависимостей. Если ваше приложение зависит от внешних сторонних служб, которые не контролируются напрямую, составьте план устранения сбоев. Создайте документацию для запланированных процессов устранения неполадок. Включите контакты службы поддержки и пути эскалации.

Используйте управление конфигурацией. Запланируйте изменения конфигурации, внесите их в операции и запишите их. Для этих целей можно использовать базу данных управления конфигурацией или подход к конфигурации как код. Регулярно проводите аудит конфигурации, чтобы убедиться, что ожидаемые параметры фактически установлены.

Получите план поддержка Azure и изучите процесс поддержки. Azure предлагает множество планов поддержки. Определите правильный план для ваших потребностей и убедитесь, что вся команда знает, как использовать план. Члены команды должны понимать детали плана, как предоставляется поддержка и как отправить запрос в службу поддержки с помощью Azure. Если вы ожидаете масштабного мероприятия, служба поддержки Azure может помочь вам с увеличением ограничений службы. Дополнительные сведения см. в разделе поддержка Azure часто задаваемых вопросы о планах.

Следуйте принципам наименьших привилегий при предоставлении доступа к ресурсам. Соблюдайте осторожность при управлении доступом к ресурсам. Запретить доступ по умолчанию, если вы явно не предоставляете пользователю доступ к ресурсу. Предоставить пользователям доступ только к тому, что им нужно для выполнения своих задач. Отслеживайте разрешения пользователей и проводите регулярный аудит безопасности.

Используйте управление доступом на основе ролей Azure. Не следует назначать учетные записи пользователей и доступ к ресурсам вручную. Используйте управление доступом на основе ролей Azure (Azure RBAC), чтобы предоставить доступ на основе удостоверений и групп идентификаторов Microsoft Entra.

Используйте систему отслеживания ошибок для отслеживания проблем. Без эффективного способа отслеживания проблем легко пропустить элементы, дублировать работу или создать новые проблемы. Не полагайтесь на "живое" общение для отслеживания состояния ошибок. Используйте средство отслеживания ошибок, чтобы записывать сведения о проблемах, назначать ресурсы для их устранения и предоставлять журнал аудита с данными о прогрессе и состоянии.

Управляйте всеми ресурсами в системе управления изменениями. Если вы включаете все аспекты процесса DevOps в систему управления и управления версиями, вы можете легко отслеживать и проверять изменения. Включите код, инфраструктуру, конфигурацию, документацию и скрипты. Все эти типы ресурсов рассматриваются как код на протяжении всего процесса тестирования, сборки и проверки.

Используйте контрольные списки. Списки проверка операций помогают выполнять процессы. Легко пропустить что-то в большом ручном руководстве, но после проверка list может заставить внимание к деталям, которые вы могли бы в противном случае пропустить. Ведите контрольные списки и постоянно ищите способы автоматизации задач и оптимизации процессов.

Следующие шаги