Эволюция DevOps

А что, что-то изменилось за последние лет 30, что можно говорить о эволюции?

Всё как и раньше, если у вас парк сложной взаимосвязанной техники с кучей разношёрстного софта, в вашем случае тоннами микросервиса, то:

- Можно автоматизировать всё, что заранее можно предсказать. При этом стоимость такой автоматизации будет превосходить стоимость продукта + его разворачивания + контракта на поддержку лет на 5-10. Ну то есть стоимость будет впечатляющей, но если оно того таки стоит, то можно.

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

ну есть куча способов бороться с неизведанным) Типичный пример: обновление сервиса разворачивается только у 5% аудитории. Если маркетинговые показатели (которые вычисляются автоматически, н-р у букинг.ком барыжит хатами, и у них это количество вписок) падают достаточно сильно, то для этих 5% происходит полный автоматический откат до предыдущей версии. А если наоборот растут, то начинается автоматическое расширение фронта. А еще они могут упасть, но незначительно (например, 10% от тех 5% упираются в ошибку) - это не откат, а заявка на автоматический мониторинг, по итогам которого тоже что-то может случиться автоматически, а может уйти разработчикам на улучшение.

а так то, у веб-сервисов основные причины отказа уже за последние пятнадцать лет вполне изучены

Имеется в виду, вот у вас упала пачка микросервисов. Кто и в каком порядке у вас будет поднимать их? Это делают админы руками, или роботы?

А с чего она упала то? Настройка таких штук уже на амазон в учебных видео показано.

А что, что-то изменилось за последние лет 30, что можно говорить о эволюции?

Наговнокодили миллионы бесполезных веб-сервисов, которые надо поддерживать. Раньше такого не было.

Ты там пропагандируешь отмирание профессии админа и профессии разработчика и вместо них хочешь оставить одного devops (программиста на ямлах).

Хотя я сама - самопровозглашенный CI Engineer, и как раз работаю именно в области continuous-всего, я думаю это некорректный подход.

Ни админы, ни разработчики никуда деваться не должны. Должен _дополнительно_ появляться CI Engineer занимающийся построением CI/CD и прочих C-пайплайнов.

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

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

P.S. Таки ты из секты Платова. Очень зря.

В области встраиваемых систем сейчас делается очень многое, чтобы устройства обходились без сисадминов. Т.е. чтобы кухарка могла рулить сложной техникой с положительным результатом и без риска для жизни, включая первоначальную установку и регулярное обновление софта. Тестируется всё это на миллиардах хомячков. Наверно, те же подходы можно применять и для этих ваших микросервисов?.. Т.е. делается такой серверообразный черный ящик с кнопками «вкл», «выкл», «установка IP-адреса», «заливка PHP-скрипта». И всё, никакое периодическое обслуживание не требуется.

ну например, сейчас есть стандартная проблема в порядке запуска сервисов. Раньше база данных должна была подниматься до приложения (иначе приложение даже не начнет запускаться), сейчас любой микросервис является источником данных для других микросервисов. Микросервис Петя просит у Васи дать список продуктов, получает в ответ null падает. Микросервис Дима просит у Пети отфильтрованные продукты, но Петя не отвечает, и Дима тоже падает. Получается каскадное падение, которое может распространиться очень сильно.

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

получает в ответ null падает.

Руки пообрывать. На то и «сервис», чтобы не падать, если во внешней среде что-то не так.

например, в Java часто используют Spring. Спринг инициализирует «контекст приложения» один раз при загрузке. Если при первоначальной загрузке какой-то параметр не подхватился, класс не создался - приложение падает к чертям. Например, если там объявляется коннектор к базе данных, а база данных еще не запущена - ничего даже не поднимется, с ошибками в Hibernate или где-то еще.

очень часто вижу, что люди используют в качестве источника данных для контекста приложения в том числе и другие сервисы. Например, распределенный ресстр конфигурации, выполненный в виде микросервиса. Например, там хранится тот же самый адрес БД. И дальше по накатанной: инициализация контекста Спринга падает или по причине недоступности сервиса, или если эту недосутпность обернули в поимку исключения - недоступность БД по адресу null, и всё падает. А так как всё зависит от всего, это каскадная ошибка, и кластер не поднимается.

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

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

Микросервис Петя просит у Васи дать список продуктов, получает в ответ null падает.

Мда... При такой архитектуре никаких врагов не нужно :).

Ох, вам бы одного моего бывшего П.М., он бы вам показал, где раки зимуют.

Например, если там объявляется коннектор к базе данных, а база данных еще не запущена - ничего даже не поднимется, с ошибками в Hibernate или где-то еще.

Видел такое когда лор пилил. Ну, наркоманы, чё, я поэтому на джаве и не программирую. Эти умеют на ровном месте проблему сделать.

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

У меня такое ощущение, что в XXI веке прогресс первым вытеснит наиболее интеллектуальные профессии. Это какое-то извращение, но мне нравится.

Сами городим проблемы, сами героически решаем. Тьфу.

Микросервис Петя просит у Васи дать список продуктов, получает в ответ null падает. Микросервис Дима просит у Пети отфильтрованные продукты, но Петя не отвечает, и Дима тоже падает.

Косорукие макаки наговнокодили, а заменять надо админа. Круто.

Правильно, админа гоним в шею и говнокодим систему автоматизации работы админа! А потом еще одну, которая будет чинить первую! Зато говнокодер в шоколаде!

А теперь идем и читаем, что такое DevOps.
(hint: это не профессия/должность)

hint: это не профессия/должность

Хуже, у каждого «своё» определение.

Просто оставлю это здесь.

https://en.wikipedia.org/wiki/Autonomic_computing

Ты это топикстартеру скажи, а не мне, после того как прочитаешь его опус.

Я пролистал его опус и там нигде нет ни слова о том, что девопс - это некий человек.

Определение - оно одно. А захотевшие поиметь на модном слове админа-программиста подешевле - это совсем другое.

Определение - оно одно

Какое же?

Т.е. криворукие программисты написали гору софта, который падает на каждый чих. Криворукие админы на этапе установки и настройки ничего не протестили и об этих падениях не знают. Но вместо того, чтобы взять нормальных специалистов ты предлагаешь нанять какого-то мифического «девопса», чтобы он в одиночку и быдлокодил и потом кое-как эту помойку настраивал?

Прочитал по диагонали.

Статья - констатация фактов.

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

Увы, когда речь идёт о чём-то более менее сложным, требующим более-менее сложной настройки(например домашний роутер), то кухарка идёт лесов в 70% случаях. В лучшем случае роутер вам настроят представители провайдера и то, только тот роутер, который они вам впарят.

А вот такая элементарщина например, как взять и покрыть одной wifi сеткой дом на 400 квадратов в несколько этажей, настраивается это одним админом без особых сложностей, хрен где продаётся в искоробочном варианте с адекватной инструкцией типо - включите точку А, нажмите кнопку Б, включите точку Б, нажмите кнопку Б.

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

я придерживаюсь определения, что девопс - это особый процесс+культура, поддержаная набором специальных инструментов. И это не какое-то бинарное отношение «есть/нет девопс», это как минимум процент внедрения этих практик. То есть, в IBM 360 тоже был девопс, хотя их практики трудно назвать идеальными

ну так можно просто держать штат админов, которые будут для автоматики писать все новые и новые «скрипты реагирования». А дело автоматики - эвристикой поймать проблему и ее связь с заготовленным скриптом. Т.е. это не планирование заранее дорогущей системы автоматизации, а пердолинг нагорячую, тот самый фигак фигак и в продакшен

у мну на работе что-то подобное было. У разных разумных технокомпаний типа Гугла, Майкрософта, Фейсбука итп тоже есть. Ну и понятно, что каждый должен стремиться стать Гуглом :) Я для себя каждую проблему начинаю с придумывания «нормального решения» - как это можно было бы сделать на нормальной гиперконвергентной среде в Гугле или ФБ, и потом уже даунскейлю на реалии текущей компании

надо потратить просто тонну времени на написание обвязки

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

Но вместо того, чтобы взять нормальных специалистов ты предлагаешь нанять какого-то мифического «девопса»,

не наять девопса, а внедрить такую культуру разработки-тестирования-администрирования, которая была бы устойчива к такому положению вещей и получала от него профит

Да можно. Да так делают, и что? Откуда вообще такой пафос то взялся, эволюция блаблабла? Так всегда делали, с тех пор как появился корпоративный софт. И так делают как правило только с копоративным софтом и железом только потому, что запредельно дорого. Все остальные живут либо создавая видимость автоматики, ну то есть чистой воды показуха и рассказы как у них там всё хорошо либо обходятся автоматикой в нескольких критичных местах + нужное количество админов.

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

стой-стой, ты говоришь, что индустрия не поменялась, но

вспоминаем Брукса и его IBM 360. Каждый день люди на тележках развозили распечатки новой версии документации, такие толстые фолианты. Которые потом читали все разработчики (админов и тестеров тоже считаем за разработчиков). И учили избранные места. Сегодня же все копипастят напрямую из гугла, ad-hoc тот кусок что нужно, и редко найдешь человека, который читал вообще оглавление документации. И наоброт, зачастую техписы не имеют архитектурного видения проекта, и вписывают док в конфлюенс только на той страничке, про которую шарят. Подход копипастинга из гугла изменил вообще всё, появилась вера в «hivemind» и автоматическое распространение знаний

или например, языки программирования. Мы достигли того уровня, когда IDE лучше знают язык, чем ты сам. Процессоры могут делать автодополнение даже по имплиситам в Скале - когда-нибудь давно, обработка одного такого автодополнения заняла бы, наверное, мощности целого оборонного вычислительного центра на день :) Благодаря этому появилась еще более крепкая вера в автомтаику - программист может писать на 10 языках одновременно (толком не зная ни одного из них). Может вписывать в любое место любой программы, даже заглядывая в ее архитектуру. И всё это вполне прилично работает! Вера в автоматику, которая всегда с тобой, всегда поможет и почистит твои косяки

или например, сама скорость разработки. Я могу добавлять фичи в Netflix OSS быстрей, чем какой-то другой человек просто придумывает, как реализовать это на существующих инструментах. А это в свою очередь стало возможным тем самым языкам, которые ты неосмотрительно назвал косметикой - например, на Java можно сильно забить на все вопросы касающиеся управлением RAM и именно поэтому можно писать фигак-фигак и в продакшен. Я видел живых людей, котоыре коммитят код даже не запуская его - так они уверены в результатах выполнения!

всё вместе сделало возможным писать «корпоративные приложения» и автоматику любому школьнику, а не мега-корпорациям типа IBM 360.

и сделало вопрос автоматики осмысленным не только для корпоративного софта, а вообще для любого софта

Красиво звучит, прямо как из буклета, да на практике сплошное дерьмо. Мне сейчас часто приходится иметь дело с корпоративным кодом на C#(не знаю, может в быть в мире Явы всё куда лучше, хотя вряд ли, ибо мир то один), так вот качество насколько жопное, что порой не работают элементарные вещи. У продуктов, которые продаются не один год может нормально не работать даже сессия, которая периодически куда-то исчезает и снова появляется логин. И это твой 21й век? Где что-то там автоматика решает? Я ещё раз повторюсь - ничего не изменилось. Подходы к разработке если где-то и изменились, то это только потому, что так дешевле, так проще, рабы ничего не стоят. Но и качество работы рабов такого, что только плакать хочется.

Да, делать теперь наколеночное дерьмо можно быстро, но это даже плохо, потому что теперь только наколеночное дерьмо все и делают. Всё остальное стоит непомерно.

И да, всякие там выдумки по поводу может писать на 10 языках - это оставь детям, хорошо? Как раз сейчас приходится заниматься парочкой проектов, которые писали вот такие вот погромисты. В результате, элементарные изменения вносить настолько сложно, что заказчик просто одобрил переписать всё с нуля. Да, ты можешь конечно писать на языке, которого не знаешь, полагаясь на рядом лежащий туториал и автокомплит. Но автокомплит не даст тебе даже знания что вообще может язык, а туториал для этого и не предназначен, это чисто старт. В итоге то что ты будешь писать, будет походить на quickbasic, ну то есть ты даже библиотеки встроенные использовать нормально не будешь, не то что там притащить какой-нибудь компонент. Но даже это просто сказка. Попробуй не зная С++ пописать на нём, скажем даже на такой простой вещи как Qt пописать. Про пописать на Java EE не зная я только упомяну.

ты противоречишь сам себе

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

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

на десяти языках сейчас любой фуллстек разработчик пишет, и это стартовое положение вещей даже для джуниорских вакансий. Например, джава-джуниор должен знать Java, SQL, JavaScript, HTML-CSS (это необходимый минимум, без которого нельзя сделать никакого веб-приложения), немного bash и/или python, возможно придется по-быстрому вникнуть в Groovy для Jenkins и Gradle. Плюс понятно что нужны какие-то фреймворки типа Spring и Hibernate для Java и React для JavaScript, на голых языках никто не кодит, а фреймворки по сути задают над-языки.

узкие специалисты может быть и есть, но их нужно мало и узко. Основная масса - это как раз фулстеки. Фулстек джава-веб, фулстек UI (который и нарисовать, и на реакте написать), фулстек инженер/исследователь автоматизации (кого на суржике принято называть «девопс»), фулстек администратор (который всё от PDP-10 до прототипов Cisco 2017 года), фулстек автотестер (который и модульные, и интеграционные, и UI, и авторегресс, и все остальное), итп

совершенно очевидно, что даже два класса из этого сочетать уже сложно

но «10 языков» к этому не относится, это как раз норма

Теперь убираем отсюда слово «fullstack» как ничего не значащее и получаем нормальную классическую терминологию.

Человек который пишет диссер в техе, хранит в гите, а примеры кодит на maple/maxima/mathematica/whatever - это не fullstack-математик, а просто грамотный пользователь своих инструментов.

Грепать и патчить по три строчки в любом языке - это вообще уровень junior support и у всех должен быть, как правописание и устный счёт.

не смог.
ожидал рассуждение на тему стейта, борьбы со сложностью в виде наращивание бюрократии и штата, идемпотентности, NoOps
но, серьёзно? шеф хочет съесть? what?

очень много мелочи которая вообще не является темой треда, а просто частный случай инструмента.
возьмём микросервисы — это ответ индустрии на проблему. это не решение проблемы. это не эволюция некой сущности называемой «современное айти», если в твоём ключе рассуждать — это реакция иммунитета на рак вроде Big ball of mud
вот только реакция иммунитета может убить раньше чем болезнь.
и вообще, у тебя есть предметная область, в ней куча терминов, накой хрен гены и прочие штуки приплетать. но это вкусовщина.

в общем основная критика — цитата со вчерашнего хабра:

Я слишком занят чтобы что-либо предпринять

ты настолько погружен в отдельные проблемы, что для тебя — это и есть реальность. вся эта мелочь вроде service discovery для тебя и есть «эволюция», за этими деревьями не видно леса

хорошо, а в чем лес?

давай рассуждать.
зачем нужен докер? самый простой ответ — управление состоянием, stateless
зачем нужен stateless? потому, что есть dependency.
зачем нужен докер, если можно сделать нормальный dependency management? его нельзя сделать. по историческим причинам очень много денег крутится в бизнесах и нет обратной совместимости.
это не принесёт дополнительную сверхприбыль, а значит нужны костыли в виде изоляции, докер.
пример ни как не описывает эволюцию или отбор. докер — не эволюция, а компромисс, костыли.
можно разобрать другие базворды, даже серьёзнее, чем пара поверхностных утверждений без пруфов.
почти всегда будем упираться в бизнес и его инертность.
эволюция?
дополню:
почти весь базис IT построен на ужасных решениях, которые в процессе отбора просто не выжили бы.
но из за накачки баблом, от них нельзя отказаться, почти никак. из за этого в борьбе со сложностью появляется Ops и «мишура» вокруг. толпы людей каждый день не дают потонуть деньгам, латая гнилой плот.

докер - это скорее мутация

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

типа такого:

https://www.hastexo.com/blogs/florian/2016/02/21/containers-just-because-ever...

И вместо майнтейнера пакетов или release engineer в дистрибутивах у нас появляется должность fullstack-platform-integration-что-то-там человек, который занимается наполнением, безопасностью и релизным циклом базовых docker-образов, на которые потом fullstack-web-developer-не-пойми-кто лепят свои микросервисные микро-слои.

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

(например домашний роутер), то кухарка идёт лесов в 70% случаях.

такая элементарщина например, как взять и покрыть одной wifi сеткой дом на 400 квадратов в несколько этажей

Ыыы... http://www.amplifi.com

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

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

За долгие годы мне подобное встречалось только с одним старым тп-линком. А их через меня прошло множество...

Микросервис Петя просит у Васи дать список продуктов, получает в ответ null падает. Микросервис Дима просит у Пети отфильтрованные продукты, но Петя не отвечает, и Дима тоже падает. Получается каскадное падение, которое может распространиться очень сильно.

Еще у классиков было:

ПУШКИН И ГОГОЛЬ 
Гоголь падает из-за кулис на сцену и смирно лежит. 
Пушкин (выходит, спотыкается об Гоголя и падает): Вот черт! Никак об Гоголя! 
Гоголь (поднимаясь): Мерзопакость какая! Отдохнуть не дадут. (Идет, спотыкается об Пушкина и падает.) Никак об Пушкина спотыкнулся!
Пушкин (поднимаясь): Ни минуты покоя! (Идет, спотыкается об Гоголя и падает.) Вот черт! Никак опять об Гоголя! 
Гоголь (поднимаясь): Вечно во всем помеха! (Идет, спотыкается об Пушкина и падает.) Вот мерзопакость! Опять об Пушкина! 
Пушкин (поднимаясь): Хулиганство! Сплошное хулиганство! (Идет, спотыкается об Гоголя и падает.) Вот черт! Опять об Гоголя! 
Гоголь (поднимаясь): Это издевательство сплошное! (Идет, спотыкается об Пушкина и падает.) Опять об Пушкина! 
Пушкин (поднимаясь): Вот черт! Истинно, что черт! (Идет, спотыкается об Гоголя и падает.) Об Гоголя! 
Гоголь (поднимаясь): Мерзопакость! (Идет, спотыкается об Пушкина и падает.) Об Пушкина! 
Пушкин (поднимаясь): Вот черт! (Идет, спотыкается об Гоголя и падает за кулисы.) Об Гоголя! 
Гоголь (поднимаясь): Мерзопакость! (Уходит за кулисы.) За сценой слышен голос Гоголя: "Об Пушкина!"
Занавес.