Длинная 4D-статья поможет вам понять, что такое DevOps.

задняя часть DevOps

Делитесь техническими знаниями в области Java, .NET, Javascript, эффективности, разработки программного обеспечения, языков программирования и т. д.

эта статьяGitHub TechShareВ комплекте, без рекламы, просто для удовольствия.

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

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

Определение DevOps

После развития DevOps на протяжении многих лет его определение постоянно меняется.Давайте сначала посмотрим на три определения DevOps в вики.

  1. DevOps 2017-2020 определение английской вики (буквальный перевод)

    DevOps — этоКультура и практика разработки программного обеспечения (практики), целью которого является интеграция разработки программного обеспечения, эксплуатации и обслуживания программного обеспечения. Главной особенностью движения DevOps является решительная пропаганда комплексной автоматизации и мониторинга всех аспектов создания программного обеспечения (от интеграции, тестирования, выпуска до развертывания и управления инфраструктурой). Целью DevOps является сокращение циклов разработки, увеличение частоты развертывания, и выпускать более надежно, в соответствии с бизнес-целями.

  2. Определение DevOps 2021 английской вики (буквальный перевод)

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

    Другой:

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

  3. Определение китайской вики DevOps

    DevOps (сочетание разработки и эксплуатации) - это акцент на отношениях между «разработчиками программного обеспечения (Dev)» и «специалистами по ИТ-операциям (Ops)».Общение и сотрудничествокультура, движение или практика. Автоматизируя процесс «доставки программного обеспечения» и «архитектурных изменений», он делает создание, тестирование и выпуск программного обеспечения более быстрым, частым и надежным.

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

Кроме того, вы можете видеть, что определения, непосредственно переведенные с английского, содержат «упражняться", а китайская вики стала "" после определенного перевода или локализациикультура, движение или условность», что также подчеркивает взаимосвязь между разработкой и эксплуатацией и обслуживаниемОбщение и сотрудничествоВ связи с этим сочетание последнего определения вики на английском языке с определением вики на китайском может помочь нам лучше понять DevOps, поэтому читатели и друзья должны понять, каково его окончательное определение.

Опыт разработки DevOps

Почему DEVOPS будет настолько популярным, часто упомянутым, это не открыто для своего развития своего развития, в основном из-за следующих моментов:

  1. Увеличение agile-потребностей, т. е. увеличение исследовательской работы;

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

  2. Доля деятельности по разработке программного обеспечения в бизнес-деятельности предприятий увеличивается;

    • Зависимость развития бизнеса от программного обеспечения превратилась из легкой и умеренной зависимости в нынешнюю сильную зависимость.

  3. Предприятиям необходимо ликвидировать отходы.

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

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

Принципы и практика DevOps

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

golden_circle.png

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

Принципы DevOps

DevOps состоит из следующих трех принципов:

  1. Принцип потока:ускоритьПроцесс от разработки, эксплуатации и сопровождения до поставки клиентам;
  2. Принципы обратной связи: конструкцияБезопасный и надежныйСистема работы;
  3. Принцип непрерывного обучения и экспериментирования: применение научного метода работы поможетУлучшайте и внедряйте инновациикак часть работы.

принцип потока

  1. настаивать на том, чтобы делать меньше

    • Разработка продукта начинается с принципов MVP.
    • Вычитание должно производиться своевременно во время итерации продукта.

  2. Непрерывная проблема разложения

    • Крупные изменения или требования разбиваются на серию небольших изменений и быстро решаются.

  3. визуализация работы

    • Визуализируйте работу с помощью Sprint Kanban.

  4. Контролируйте количество задач

    • Сократите время выполнения заказа и сократите время ожидания тестировщиков.
    • Чем больше задач, тем менее точная оценка.

  5. Уменьшить количество хендоверов

    • Сократите ненужное общение и ожидание.

  6. Постоянно выявляйте и улучшайте точки ограничения

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

  7. Устранение затруднений и потерь из потока создания ценности (основной фактор задержек доставки)

    • Полуфабрикат - работа, которая не полностью завершена.
    • Дополнительные шаги — документация, которая никогда не используется, переписывание документации по интерфейсу и т. д.
    • Дополнительные функции — функции, которые пользователю на самом деле не нужны.
    • Переключение задач — назначайте людей на несколько проектов или отдельные рабочие задачи.
    • Ожидание, переезд, баги, нестандартные ручные операции.

принцип обратной связи

  1. Безопасная работа в сложных системах

    • Управлять сложными работами и выявлять проектные и эксплуатационные проблемы;
    • Мозговой штурм по решению проблем для быстрого накопления новых знаний;
    • Применение региональных знаний в масштабах всей организации в глобальном масштабе;
    • Лидеры должны продолжать развивать людей с этими талантами.

  2. Своевременное обнаружение проблем

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

  3. Гарантия качества у источника

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

  4. Оптимизация работы для внутренних клиентов

    • Эксплуатационные нефункциональные требования (такие как архитектура, производительность, стабильность, тестируемость, конфигурируемость и безопасность) так же важны, как и пользовательские функциональные возможности.

Принципы непрерывного обучения и экспериментирования

  1. Построение обучающейся организации и культуры безопасности
  2. Институционализировать улучшения в повседневной работе
  3. Превращение локальных открытий в глобальную оптимизацию
  4. Внедрите шаблоны устойчивости в свою повседневную работу
    • Сокращение времени развертывания, улучшение охвата тестами, сокращение времени выполнения тестов и даже разделение архитектуры, если это необходимо, — все это примеры методов, которые создают аналогичные проблемы в системе.
  5. Лидерство укрепляет культуру обучения
    • Лидеры помогают передовым работникам выявлять и решать проблемы в их повседневной работе.

Практики DevOps

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

разработать организационную структуру

  • Используйте закон Конвея для разработки командных структур.
    • Закон Конвея: архитектура программного обеспечения такая же, как и структура команд разработчиков.
    • Архитектура программного обеспечения должна гарантировать, что небольшие группы могут работать независимо и полностью отделены друг от друга, чтобы избежать чрезмерного или ненужного взаимодействия и координации.
  • Опасности чрезмерной функциональной направленности (оптимизация затрат).
    • Люди, выполняющие работу, часто не понимают, как их работа связана с целями потока создания ценности («Я настраиваю этот сервер, потому что кто-то сказал мне это»).
    • Проблема усугубляется, когда каждая функциональная группа в операционном отделе одновременно обслуживает несколько потоков создания ценности (т. е. несколько групп разработчиков), потому что время всех команд драгоценно.
  • Создавайте команды, ориентированные на рынок.
    • Внедрите инженеров и их опыт (например, операции, контроль качества и информационную безопасность) в каждую группу обслуживания или предоставьте группам платформу самообслуживания, которая может настраивать среды, подобные производственной, выполнять автоматизированные тесты или развертывать.
    • Это позволяет каждой сервисной группе самостоятельно приносить пользу клиентам, не отправляя запросы в другие отделы, такие как ИТ-эксплуатация, контроль качества или информационная безопасность.
  • Сделайте функциональную ориентацию эффективной.
    • Быстрый ответ.
    • Культура высокого доверия.
  • Интегрируйте тестирование, эксплуатацию и информационную безопасность в свою повседневную работу.
    • Обеспечение качества, доступности и безопасности — это не обязанность одного отдела, а часть повседневной работы всех.
  • Сделайте членов команды универсалами.
    • Обучайте full stack инженеров.
    • Предоставьте инженерам возможность приобрести необходимые навыки, чтобы они могли построить и запустить ответственную систему.
  • Свободно связанная архитектура для повышенной производительности и безопасности.
  • Держите его маленьким («правило двух пицц»).

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

oaas.png

Интеграция эксплуатации и технического обслуживания в работу по разработке проекта

  • Создавайте общие сервисы (такие как производственные среды, конвейеры развертывания, инструменты автоматизированного тестирования, консоли мониторинга производственной среды, платформы обслуживания эксплуатации и обслуживания и т. д.) для повышения производительности разработки.
  • Инженеры по эксплуатации интегрированы в команду разработчиков.
    • Сделайте продуктовые команды самодостаточными и полностью ответственными за предоставление услуг и поддержку.
    • Направляйте инженеров в группу разработки проекта (собеседования и наем инженеров по эксплуатации по-прежнему проводит централизованная операционная группа).
  • Назначьте связных по эксплуатации (отправленных инженеров по эксплуатации) для каждой проектной группы.
    • Централизованная группа эксплуатации и обслуживания управляет всеми средами, а назначенные инженеры по эксплуатации и обслуживанию должны понимать: функцию нового продукта, причину разработки, принцип работы программы, работоспособность, масштабируемость, возможность мониторинга, архитектурный шаблон, требования к инфраструктуре, план выпуска функций продукта и т. д.
  • Приглашайте операционистов на собрания команды разработчиков, ежедневные стендапы, ретроспективы.
  • Используйте диаграммы канбан для отображения работы операций.

Механизация технологии потока

Этот раздел содержит следующее:

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

Основы запуска конвейера развертывания

  • Построение автоматизированной среды (разработка, тестирование, официальная).
    • Используйте Shell, IaC (Puppet, Ansible, Terraform), Docker, K8S, OpenShift и другие технологии.
  • Весь контент контролируется версиями.
    • контроль версий кода приложения;
    • Контроль версий кода базы данных;
    • Контроль версии кода конфигурации эксплуатации и обслуживания;
    • Скрипты для автоматизированного и ручного тестирования;
    • Пакет поддержки кода, развертывание, миграция баз данных, скрипты, конфигурация приложения;
    • Документы, связанные с проектом (документация требований, процесс развертывания, примечания к выпуску и т. д.);
    • Скрипты для настройки брандмауэра, настройки сервера и т.д.
  • Расширьте определение завершения.
    • Работа по разработке считается завершенной, когда она идет, как и ожидалось, в среде, близкой к производственной.

Обеспечьте быстрое и надежное автоматизированное тестирование

  • Постоянно строить, тестировать и интегрироваться.
    • Код ветвей непрерывной интеграции в багажник и обеспечивает пробное тестирование единиц, тестирование интеграции и тестирование приема.
    • Общие инструменты: Jenkins, TFS, TeamCity, GitLab CI.
    • Совместимость с непрерывной интеграцией: инструменты автоматизированного тестирования, культура сбоев, которые необходимо устранять немедленно, код, который постоянно сливается в ствол, вместо того, чтобы постоянно работать над ветками функций.
  • Создавайте быстрые и надежные наборы автоматизированных тестов.
    • Модульное тестирование: JUnit, Mockito, PowerMock
    • Метрики модульного тестирования: тестовое покрытие.
    • Приемочное тестирование: автоматизированное тестирование API, автоматизированное тестирование графического интерфейса.
    • Параллельные тесты: тестирование безопасности, тестирование производительности, тестирование единиц, автоматическое тестирование.
    • Разработка через тестирование: TDD, ATDD.
  • Постоянно держите конвейер развертывания в зеленом состоянии.
    • В случае сбоя конвейера развертывания все немедленно решают проблему или немедленно откатывают код, а последующие отправки кода следует отклонять.

непрерывная интеграция кода

  • Код непрерывной интеграции.
    • Чем дольше разработчики работают независимо над своими ветками, тем сложнее вносить изменения в основную ветку.
  • Развитие небольших количеств.
  • На основе развития ствола.
    • Часто фиксирует (через мерж-реквесты) код в транке.

Автоматизированные выпуски с низким уровнем риска

  • Шаги автоматизированного развертывания: сборка, тестирование, развертывание; связанные процессы включают в себя:
    • Код упаковки и конструкции;
    • Загрузить Docker Image;
    • Создать предварительно обработанную услугу K8S;
    • Автоматизированное модульное тестирование, дымовое тестирование;
    • Автоматизация миграции баз данных;
    • Настроить автоматизацию.
  • Самостоятельное развертывание автоматизации приложений
    • Разработчики сосредотачиваются на написании кода, нажимают кнопку развертывания и видят, что код нормально работает в производственной среде с помощью индикаторов мониторинга, и могут получить информацию об ошибках, чтобы быстро исправить, когда код пойдет не так.
    • Благодаря проверке кода, автоматическому тестированию, автоматическому развертыванию, контролю рисков развертывания, чтобы разработчики могли быть развернуты при необходимости, тестировщики и менеджеры проектов могут быть развернуты в некоторых средах.
  • Разделите развертывание и выпуск
    • Развертывание относится к установке определенной версии программного обеспечения в определенной среде.
    • Выпуск означает предоставление возможности продукта всем или некоторым клиентам.
  • Режим публикации на основе среды
    • сине-зеленое развертывание
    • Оттенки серого (канарейка)
  • Режим выпуска приложений
    • Реализовать переключение характеристик, преимущества: простой откат, снижение нагрузки на производительность, блокировка зависимости от службы.
    • Внедрение черного старта: неявно вызывается при выпуске потенциально опасной новой функции и записывает только результаты тестирования.
  • Практика непрерывной доставки
    • Непрерывная поставка означает, что все разработчики работают над стволом небольшими партиями или над ветками функций, которые существуют в течение короткого периода времени, и регулярно сливаются с стволом, при этом всегда поддерживая выпуск ствола и возможность делать это в обычном режиме. публикация по запросу в рабочее время. Разработчики получают быструю обратную связь при внесении любых регрессионных ошибок (включая ошибки, проблемы с производительностью, проблемы с безопасностью, проблемы с удобством использования и т. д.). После выявления эти типы проблем решаются немедленно, сохраняя магистраль всегда в готовом к развертыванию состоянии.
  • Практика непрерывного развертывания
    • Непрерывное развертывание означает, что на основе непрерывной доставки разработчики или персонал по эксплуатации и обслуживанию регулярно развертывают высококачественные версии сборки в производственной среде в режиме самообслуживания, что обычно означает, что каждый человек выполняет по крайней мере одно развертывание производственной среды каждый день. , Когда человек фиксирует изменение кода, запускается автоматическое развертывание.
  • Большинство команд используют методы непрерывной доставки.

Архитектура для снижения риска релиза

  • Свободно связанная архитектура
  • Сервис-Ориентированная Архитектура
  • Безопасное развитие корпоративной архитектуры
    • Режим приложения Strangler: API инкапсулирует существующие функции, реализует новые функции в соответствии с новой архитектурой и управлением версиями API.
  • облачная архитектура

Техническая практика обратной связи

Этот раздел содержит следующее:

  • Построение системы телеметрии
  • Умное оповещение
  • Отзыв о приложении для безопасного развертывания
  • Применить A/B-тестирование
  • Установите процесс обзора и сотрудничества

Построение системы телеметрии

  • Что такое телеметрия?
    • Телеметрия включает в себя мониторинг, позволяющий осуществлять высокоскоростной и более детальный мониторинг сети в режиме реального времени.
    • По сравнению с традиционной технологией мониторинга сети, телеметрия активно отправляет информацию о данных в сборщик через режим push, обеспечивая более быстрые и точные функции мониторинга сети в режиме реального времени.
  • Три размера телеметрии
    • Отслеживание, метрики, ведение журнала.
  • наблюдаемость
    • Система может определить степень своего внутреннего состояния по внешнему выводу (данным телеметрии).
    • Может выявлять, прогнозировать и решать проблемы.
  • Централизованная система мониторинга (в наличии: Prometheus, SkyWalking)
    • Собирайте данные на уровнях бизнес-логики, приложения и среды.
    • Маршрутизатор событий, отвечающий за хранение и пересылку событий и метрик.
  • Телеметрия журнала приложений (ELK, журнал аудита, метрики)
  • Список основных событий приложения:
    • Результаты аутентификации/авторизации (включая вывод);
    • доступ к системам и данным;
    • изменения в системах и приложениях (особенно изменения привилегий);
    • Изменения данных, такие как добавление, изменение или удаление данных;
    • Неверный ввод (возможна вредоносная инъекция, угрозы и т. д.);
    • ресурсы (память, диск, ЦП, пропускная способность или что-то еще с жесткими/мягкими ограничениями);
    • здоровье и доступность;
    • запуск и отключение;
    • неисправности и ошибки;
    • сработал автоматический выключатель;
    • Задерживать;
    • Успешное/неудачное резервное копирование.
  • Включите телеметрию строительного производства в свою повседневную работу по разработке.
  • Используйте телеметрию для решения проблем.
  • Создание визуальной телеметрической информационной системы самообслуживания доступа (информационные излучатели)
    • Grafana
    • SkyWalking
    • Kibana
  • Найдите и заполните слепые зоны телеметрии (создайте полную и завершенную телеметрию)
    • Бизнес-уровень: объем заказа, количество пользователей, коэффициент оттока, показы рекламы и клики и т. д.
    • Уровень приложений: события обработки транзакций, сбои приложений и т. д.
    • Уровень инфраструктуры: пропускная способность сервера, загрузка процессора, использование диска и т. д.
    • Уровень клиентского ПО: ошибки и сбои приложений, события клиентских транзакций и т. д.
    • Уровень конвейера развертывания: статус конвейера, частота развертывания и т. д.

Умное оповещение

  • Усталость от бдительности
    • Достаточная и полная телеметрия приводит к проблемам усталости предупреждений, которые требуют более интеллектуальных предупреждений.
  • Используйте методы статистического анализа вместо статических порогов для установки предупреждений
    • Использовать среднее и стандартное отклонение (для данных с нормальным распределением): оповещения, когда метрические данные имеют большое стандартное отклонение от среднего.
  • Используйте оповещения, которые предотвращают сбои, а не просто оповещения после сбоя
    • Попробуйте спросить, по каким показателям можно предсказать неудачу.
  • Технология обнаружения аномалий
    • Статистический метод сглаживания. Используя скользящее среднее, данные преобразуются путем получения среднего значения каждой точки и всех других данных в скользящем окне.
    • Инструменты, поддерживающие расширенное обнаружение аномалий: Prometheus, Grafana.

Отзыв о приложении для безопасного развертывания

  • Сделайте развертывание более безопасным с помощью телеметрии — проблемы выявляются сразу после развертывания.
  • Все в потоке создания ценности (разработчики, менеджеры по развитию, архитекторы, операционные группы и т. д.) разделяют ответственность за инциденты, связанные с эксплуатацией.
    • Совместно выполнять дежурную работу и совместно решать проблемы производственной среды.
  • Позвольте разработчикам отслеживать влияние работы на операторов.
    • Упростите развертывание разработанных приложений и повысьте уровень удовлетворенности эксплуатационного и обслуживающего персонала.
  • Позвольте командам разработчиков самим управлять производственными службами.
    • Управляется сначала командой разработчиков, а затем группой централизованных операций.
    • Инженеры по эксплуатации и обслуживанию переходят от поддержки производства к консультантам или присоединяются к командам, чтобы помочь подготовиться к развертыванию и установить рекомендации по выпуску услуг (включая: поддержку эффективного мониторинга, надежное развертывание, архитектуру, поддерживающую быстрое и частое развертывание и т. д.).
    • Распределите сотрудников SRE по командам. Позиционирование SRE: SRE означает, что инженеры-разработчики программного обеспечения несут ответственность за работу по эксплуатации и обслуживанию SRE встречается очень редко и может быть назначено только самым важным командам.

Применить A/B-тестирование

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

Установите процесс обзора и сотрудничества

  • Предотвращает «чрезмерные изменения управления»
    • Контрфактическое мышление склонно предполагать, что несчастные случаи происходят из-за отсутствия процессов утверждения.
  • Установите экспертные оценки, чтобы сократить процесс утверждения
    • Высокоэффективные организации в DevOps больше полагаются на экспертные оценки и меньше на внешние утверждения изменений (уровни утверждений).
  • проверка кода
    • Когда каждый код привязан к стволу, он должен пройти рецензирование;
    • Каждый должен следить за представлениями других членов;
    • Определите изменения с высоким риском, чтобы определить, должны ли они быть рассмотрены экспертами в предметной области;
    • Разделите большие изменения фиксации на более мелкие пакеты изменений.
  • Улучшайте изменения кода с помощью парного программирования
    • Исследования показывают, что программисты, работающие в паре, на 15% медленнее, чем два программиста, работающих независимо друг от друга, а количество «безошибочного» кода увеличивается с 70% до 85%.
    • Стоимость тестирования и отладки программы часто во много раз превышает стоимость написания исходного кода.
  • Оценивать валидность мерж-реквестов
    • Независимо от результата в производственной среде.
    • Важные элементы действительного запроса на слияние: причина изменения, способ его внесения, а также любые выявленные риски и ответы должны быть описаны достаточно подробно.

Техническая практика непрерывного обучения и экспериментирования

Этот раздел содержит следующее:

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

Интегрируйте обучение в повседневную работу

  • Просто культура и культура обучения
    • Человеческая ошибка часто не является основной причиной проблемы, но может быть результатом неизбежных проблем проектирования в сложных системах.
    • Не следует «призывать, обвинять и стыдить» тех, кто несет ответственность за неудачи, и наша цель — максимизировать возможности организационного обучения.
    • Посмотрите на ошибки, ошибки, ошибки, ошибки и т. д. с точки зрения обучения.
    • Соответствующая практика 1: при последующем анализе не обвиняйте, судите справедливо, побуждайте самих инженеров брать на себя ответственность за происходящее и с энтузиазмом помогайте другим избегать тех же ошибок; широко представляйте результаты посмертных совещаний.
    • Соответствующая практика 2: Внедрите контролируемые человеческие ошибки (проблемные обезьяны) в производственную среду, чтобы отрепетировать неизбежные проблемы.
  • Снижайте устойчивость к авариям и ищите более слабые сигналы неисправности
    • С улучшением организационных возможностей количество инцидентов значительно снижается, и сбоев быть не должно.
    • В сложных системах усиление слабых сигналов неисправности имеет решающее значение для предотвращения катастрофических отказов.
  • переопределить не удалось
    • Высокопроизводительные организации DevOps меняются в 30 раз чаще, чем в среднем, и даже если уровень отказов составляет половину среднего, это явно означает большее количество общих отказов.
    • Поощряйте инновации и принимайте связанные с ними риски.
  • Устройте день аварийной тренировки
    • Помогите командам смоделировать и отрепетировать инциденты, чтобы подготовить их к бою.
    • Выявить потенциальные недостатки в системе.

Превратите локальный опыт в глобальное улучшение

  • [ChatOps] Использование чат-ботов, накопление организационных знаний
    • Автоматизированные инструменты, интегрированные в чат, например, (@bot depoy owl to production);
    • Результат операции отправляется ботом обратно в чат, и все могут видеть, что произошло;
    • Новые инженеры также могут видеть ежедневную работу и исполнение команды;
    • Люди также склонны искать помощи, когда видят, что другие помогают друг другу;
    • Используйте тематические группы для организации организационного обучения, и знания быстро накапливаются.
    • Укрепляется культура прозрачности и сотрудничества.
  • Перевод стандартов, процессов и спецификаций в форму, удобную для реализации
    • [ArchOps] Сделайте инженеров строителями, а не каменщиками;
    • Преобразование ручных операционных процессов в код, который может выполняться автоматически;
    • Выражайте соответствие с помощью кода.
  • Документируйте и распространяйте знания с помощью автоматизированного тестирования
    • Автоматизированное тестирование интерфейса, чтобы пользователи знали, как используется система;
    • Модульные тесты, чтобы вызывающая сторона знала, как используется API метода.
  • Разработка проекта включает нефункциональные требования к эксплуатации и техническому обслуживанию.
    • Адекватная телеметрия для различных приложений и сред;
    • возможность точного отслеживания зависимостей;
    • Сервисы, которые являются устойчивыми и изящно деградируют;
    • Передняя и обратная совместимость между версиями;
    • Возможность архивирования данных для управления производственными наборами данных;
    • Возможность легкого поиска и понимания различной информации журнала обслуживания;
    • Возможность отслеживать запросы пользователей через несколько сервисов;
    • Используйте переключатели функций или другие методы для простой централизованной настройки во время выполнения.
  • Внедрение пользовательских историй многоразовых операций в разработку
    • Реализуйте повторяющиеся операции и работы по техническому обслуживанию с помощью кодирования.
  • При выборе технологии необходимо учитывать факторы эксплуатации и технического обслуживания.
    • нельзя тормозить рабочий процесс;
    • Рассмотрим пример: как выбрать TIDB VS MySQL.

Выделите время для организационного обучения и совершенствования

  • Институционализация погашения технического долга
    • Регулярная «уборка»
    • Dev и Ops оптимизированы с учетом нефункциональных требований и охватывают весь поток создания ценности.
    • Стоимость: Персонал Front-Line был предоставлен возможность идентифицировать и решать проблемы.
  • Пусть все учатся друг у друга
    • Всем инженерам все чаще нужны определенные навыки, а не только разработчикам.
    • Все больше технологических потоков создания ценности используют принципы и шаблоны DevOps.
    • [Культура еженедельного обучения] Существует еженедельное время обучения, когда каждый компаньон учится сам и учит других.
  • Внутренние консультанты и коучи
    • Создайте внутреннюю коучинговую и консультационную организацию для содействия распространению опыта внутри организации.

Практическая направленность

Практики DevOps включают в себя много элементов, утонченные фокус для легкого доступа:

  • Практика принципа мобильности
    • Основа конвейера развертывания (весь контент контролируется версиями и завершается, как ожидается, в рабочей среде)
    • Обеспечивает быстрое и надежное автоматизированное тестирование (запускается автоматически, постоянно поддерживает зеленый конвейер)
    • Непрерывная интеграция кода (разработка небольшими партиями)
    • Автоматизированные выпуски и выпуски с низким уровнем риска (самостоятельное развертывание, разделение развертывания и выпуска, непрерывная доставка)
    • Архитектура для снижения риска выпуска (собственная облачная архитектура)
  • Практика принципа обратной связи
    • Построение систем телеметрии (трассировка, метрика, ведение журнала)
    • Умные оповещения (оповещения, использующие методы статистического анализа и предотвращающие сбои)
    • Обратная связь с приложением для безопасного развертывания (проблемы выявляются сразу после развертывания, общая ответственность)
    • Применять A/B-тестирование (интегрировать A/B-тестирование в функциональное планирование, использовать переключатели функций)
    • Установите процессы проверки и сотрудничества (проверка коллег, упрощенный процесс утверждения, парное программирование)
  • Практика принципов непрерывного обучения и экспериментирования
    • Интегрируйте обучение в повседневную работу (рассмотрите несчастные случаи с точки зрения обучения, ищите более слабые признаки отказа)
    • Превратите локальный опыт в глобальные улучшения (ChatOps, упрощение выполнения спецификаций, нефункциональные операционные требования)
    • Выделите время для организационного обучения и совершенствования (своевременное погашение технического долга, преподавание и обучение, внутреннее обучение)

Эпилог

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

Для всех профессионалов, которые любят инновации и перемены, у нас впереди светлое и яркое будущее.

Эта статья заканчивается от автора, чтобы поделиться ppt, ppt и исходным адресом:GitHub.com/lcomplete/T…

Категории