Движение DevOps

Больше, чем просто предоставление разработчикам доступа!

Или даже не это. Большая идея, стоящая за “движение” не просто дать разработчикам больше веревки; речь идет об обеспечении лучших линий связи между разработчиками и операциями команд на предприятии. Большая часть этого не нова, на самом деле это перестройка движения kaizen в рамках традиционных производственных (специальных автомобильных) цепочек поставок в течение предыдущего века. Доски Kanban – это лишь последнее обновление информационных панелей с высоты птичьего полета (удвоение в качестве менеджеров запасов рабочего процесса), охватывающее коллективные ежедневные усилия по отправке качественных продуктов, которые радуют клиентов и деловых партнеров.

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

Разработка на основе магистральных линий

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

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

        Surgery on a patient must result
        in good outcomes (at all times) for
        that patient, not just for siblings
        or future generations.

Конвейеры CI/CD

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

Код есть закон (разработка + инфраструктура + конфигурация)

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

Назад в пре-CFEngine В течение нескольких дней Фонд программного обеспечения Apache хранил все свои файлы ИТ-конфигурации и скрипты поддержки в CVS, а затем Subversion. Кроме того, каждый выполняемый нами сервис связан с “беговая книга” для руководства администраторов с их практическим обслуживанием.

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

В настоящее время они хранят все в git-поддерживаемое дерево кукольных исходников, а также инициализация/развертывание/конфигурация непосредственно в облаке с использованием общих предшествующих пакетов Ubuntu, что является несколько современным подходом к их работе ИТ-операций, поскольку запланировано git вытаскивание марионеточным мастером в конечном итоге приведет к развертыванию обновлений по мере возврата агентов марионеток обратно. Но непрерывная интеграция и развертывание (CI/CD) – это процесс, который продолжается и по сей день.

С другой стороны, ранняя, новаторская CI-подобная инициатива в ASF (для реальных проектов программного обеспечения Apache TLP) была Гамп, АпачЭто было детищем блестящих коллег, таких как Сэм Руби и компания. То, что сделал Гамп, это периодическая проверка, сборка и тестирование HEAD (включая HEAD всех Deps) багажника каждой кодовой базы в репозитории Subversion (но восходит к CVS) для каждого проекта, который он мог успешно выяснить, как построить (который был по большому счету ограничен проектами Java изначально). Отчеты автоматически отправляются каждому сообществу разработчиков и архивируются для потомков. Эта проницательная активность автоматизации работы продолжается (с git) и по сей день! Любое сообщество разработчиков корпоративного размера, не работающее на своем собственном сервере Gump, находится на 20y позади современного состояния в ASF (на мой взгляд, не начинайте меня с зависимостей программных модулей с открытым исходным кодом в /trunk|master/ …).

В двух словах: все ваши источники (разработка, инфраструктура и конфигурация) относятся к контролю версий (не обязательно к одному и тому же репозиторию), который можно просмотреть всем сотрудникам DevOps, и являются частью вашего полного набора конвейеров автоматизации тестирования между версиями исправлений и производственными развертываниями. Опрос о состоянии техники, где изменения тестируются / предоставляются / развертываются по требованию в настройках IaC / CaC, находится на сайте моего друга и визионера Пола Хамманта здесь. Пожалуйста, посмотрите!

Сравнение виртуализации и контейнеризации

А Домашние животные против скота Возврат.

Контейнерные системы, такие как Docker, представляют собой настраиваемые, повторно развертываемые технологии виртуализации, которые обычно используются для поддержки кластерной структуры приложений архитектуры MicroService (MSA), такой как Kubernetes. Они выбирают то место, где остановились системы виртуализации, торгуя неограниченной поддержкой (полностью) изолированных операционных систем на виртуальную машину для виртуальных машин на базе ядра Linux, которые имеют значительно более программируемую настройку и интеграцию с родительским хостом Linux, на котором они работают. Кроме того, они могут быть перестроены и загружены в централизованную службу распределения (например, артефакт) для широкомасштабного повторного использования в нескольких цепочках зависимостей и развертываниях необработанных исполняемых серверов.

Вертикальное и горизонтальное масштабирование

Перенастраиваемые контейнеры, загружаемые с центрального сервера, дают возможность, которую трудно реализовать с помощью базовой технологии виртуализации, – вы не заблокированы никакими аппаратными ограничениями одного сервера для масштабирования ваших сервисов в соответствии с спросом. Другими словами, горизонтальное масштабирование путем развертывания одного и того же контейнера в наборах хостов, по требованию, является мгновенно достижимой первоклассной функцией платформ MSA на основе Docker. При развертывании десятков контейнеров больше, чем ядер ЦП на хосте same.

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

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

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

Один из главных уроков обратного воздействия COVID-19 в начале 2020 года, как больничный потенциал с точки зрения ИТ, заключается в том, что существует такая вещь, как «слишком бережливый», по крайней мере, когда дело доходит до укомплектования персоналом (аппаратное обеспечение – это другая история). Непредвиденное планирование на дождливый день, либо с “избыточный” персонал или инициативы по перекрестному обучению, в сочетании с регулярными подготовительными упражнениями, не только держит врача подальше, но и на самом деле миссия критическая.

Присоединение к программе

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

Философия включения многочисленных заинтересованных сторон в создание и эволюцию материального рабочего продукта имеет последствия далеко не только для команд dev и ops, разделяющих контроль и ответственность за усилия по проектированию серверов. Этот урок продолжает повторяться во всем современном корпоративном мире, поскольку в бизнес-секторе формируются новые области для творческого самовыражения человека, а также придумываются старые способы ведения бизнеса вместе.