Участник:Lappy/DevOps

DevOps (пинд. DerpOps, шутл. дергопс) — форсированный стараниями интеллектуального большинства мем в IT. Под словом «девопс» понимается некая идеология, вроде коммунизма или чего похуже, которая позволит запихивать в релизы софта в овер9к больше нового функционала, а сами релизы релизить после каждой встречи разрабов в курилке. Общество, однако ж, поняло смысл термина несколько по-иному, что примерно с 2014 года и по сей день доставляет порой неимоверное количество лулзов. В частности, теперь девопсом называется и сам адепт такой идеологии.

В чём проблема?

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

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

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

Собственно, существовало ещё множество проблем, порождённых столь долгими интервалами между релизами. Но бизнес, который, как известно, за всё платит, по-настоящему интересовали только моменты вроде:

• Какого хуя всё так долго релизится?
• Какого хуя выкатили и опять всё у всех ёбнулось?
• Какого хуя вы там между собой не можете договориться, кто за что отвечает?

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

Суть ™

Поскольку единого стандарта у сабжа нет, возможно выделить примерно две идеи, с которыми соглашаются почти все адепты девопса:

• Максимальная автоматизация всего и вся. В идеале — разработчик пушит изменения кода в репозиторий, и всё само тестируется, собирается и выкатывается на прод. IRL так разве что у всяких Amazon и Netflix.
• Максимальная коллаборация всех и вся. Разработчики братаются с админами и вместе решают, каким софт должен быть, чтобы довольны были все.

Естественно, реальность несколько иная.

Последствия

Как только термин DevOps приобрёл более-менее устоявшееся значение, сразу же появились многочисленные цыганы, которые обещали научить внедрять девопс за 100500 миллиардов баксов. Серьёзные дяденьки из бизнеса, съездив на пару таких презентаций, требовали от своих CIO срочно предоставить стратегию запиливания девопса в их ООО «Рога и копыта». Внезапно, как снег зимой, вылезли следующие проблемы:

1. Никто не понимал в точности, что это такое. Многие жертвы девопса думали, что девопс — это автоматизация рутинных тасков типа обновления винды или отключения ненужных служб.

2. Никто не хотел изучать хуеву гору нового материала, посему разработчики остались разработчиками, админы — админами, но появился новый класс айтишников — девопс-инженеры. Авторы концепции сделали лицорука и объявили такой тайтл ересью, ведь подразумевалась трансформация существующей культуры в компаниях, а не подселение новых сверхлюдей к существующим старпёрам. Но было поздно.

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

4. Идеологи DevOps почему-то крайне избегали упоминание того факта, что 95% населения - идиоты. Применительно к элите нации это означало, что если в версии 1.0 продукта кнопка называется «Remove», а в версии 2.0 — «Delete», то среднестатистический специалист поймёт, что это одно и тоже. Но если кнопку убрать, скажем, в контекстное меню, то пресловутые 95% ниасилят, изойдут на говно в бложеках и IRL. Ярчайший пример — ажиотаж вокруг исчезновения кнопки «Пуск» в Windows 8. Адаптация к более кардинальным изменениям для подобных личностей приравнена к трём инфарктам.

5. Поручение сложнейших задач вида «подготовить виртуалку» и «поставить апач» скриптам вместо админов заставило последних отложить кирпичи и саботировать внедрение сабжа до последней капли крови из страха потерять работу.

6. В кровавых энтерпрайзах типа банков, страховых, энергетических и прочих здоровых контор девопс задел чувства спецов по инфобезопасности, большинство из которых воспринимает любые подобные инициативы через призму «как бы чего не вышло».

Итогом внедрений стали:

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

Настоящий девопс

Ценник на услуги девопса — по-настоящему конский. В ДС среднестатистический девопс пишет в резюме цифру от 150 тысяч рублей чистыми (около 2500 $). За эти бабки надо многое уметь:

• Поднимать инфраструктуру, то есть готовить серверы и необходимое ПО на них. Ручная конфигурация и скриптинг теперь некошерны — изволь использовать подход под названием IaC для всяких Terraform и Ansible;
• Для тех, кто эволюционировал до контейнеров — разбираться в контейнеризации и знать Kubernetes;
• Очень хорошо разбираться в системах контроля версий кода типа Git, чтобы подтирать жопы разработчикам, жалующимся, что «гит некорректно себя ведёт»;
• Собирать и деплоить проект в системах оркестрации. Лидером среди соответствующего ПО является Jenkins — убогое поделие, которое требуется обвешать плагинами по самое небалуйся, чтобы оно минимально приемлемо работало;
• Уметь замониторить приложение, для которого построены девопсные процессы. Для этого нужны тулы для аггрегации и анализа логов, такие, как ELK;
• Разбираться в облаках типа AWS, Azure и GCP.

И это только часть скиллов.