System administrators considered harmful

[elglin]

Не Дийкстра я ни разу, но хоть примажусь.
В 2016 году к нам прибежал наш внутренний идеолог Амазона и заявил, что еще полгода, и админы будут не нужны. Мы его обсмеяли, а он сейчас большой начальник; я вообще не понимаю, как он сделал карьеру на завале двух эпических проектов, продолбавших шести-, если не семизначную сумму, но вот поэтому он Бенцион Крик, а у меня в душе осень.
Ну кагбе пять лет прошло, воз миграции в Амазон и ныне там, хотя есть шанс, что он с непередаваемым скрипом таки поедет если не в этом, так в начале следующего года.
Но я не об этом. Амазон продвигает свой концепт, что надо убрать undifferentiated heavy lifting и сосредоточиться на бизнес-логике. Естественно, за помянутый heavy lifting надо немного отстегнуть Амазону, что логично. И опять же, суть не в этом, а суть в том, что разработчик в кои-то веки можно полностью контролировать стек. И это прямо-таки офигенно.
Вот я подумал за свой приклад. Да, там, конечно, внизу сервер, пицот лет конфигурять. А если вдуматься, то докерфайл будет не такой и развесистый, особливо если его собирать поэтажно, как доктор прописал. И если у меня есть докер-инфраструктура, которую не я собираю (AWS ECS/Fargate, EKS), то на докерфайле заканчивается моя зона ответственности и начинается зона... сервис-провайдера.
То же самое со всякими файрволами и балансерами (в кубиках это контролируется прямо из кубиков, в ванильном AWS - хоть терраформом, хоть CloudFormation). То же самое даже с мониторилками и логособиралками и далее по тексту.
База... ну формально я к этому постгресу рутовый доступ имею. В реальности катаешь миграции, смотришь диагностику и все такое, так что можно сказать, что и постгрес мне сгодится "как сервис". Туда же пойдет и модный редис, и любые Kafka/RabbitMQ и так далее.

То есть суть в том, что граница ответственности разраба почти везде сомкнулась с границей ответственности сервис-провайдера. Для админа, который жил как раз между этими границами, места нет. Окей, скажете вы, но ведь все эти жабаскрипт-мидлы и решетка-сеньоры ни черта не понимают в архитектуре. Ну, во-первых, понимают порой очень немало, во-вторых, можно вспомнить, что во времена оны человек, подозрительно похожий на современных SRE, назывался системным программистом и на сисопа или админа мог заслуженно оскорбиться.
Конечно, тут можно сказать, что cloud is just other people's servers, но суть в том, что в этом самом Амазоне, к примеру, классической админской работы, мне думается, мало. А за пределами Больших и Толстых провайдеров, мне думается, грядет плавное вымирание мелких и тонких.

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

Comments

[beldmit]

В общем да, для массового сервиса оно так и будет. Чужие сисадмины идут за чужими серверами. То же самое pets vs cows, только немного под другим углом.

Что такое undifferentiated heavy lifting в данном контексте?

[elglin]

В амазонспике это "усилия по поднятию годной инфраструктуры, которые принципиально не отличаются от задачи к задаче и от конторы к конторе".
Допустим, я работаю, ну, в конторе купи-продай. Мне нужна базенка, и у меня есть постгрес. Только погоди, надо же настраивать мастер с репликами, чтобы оно не валилось и выдерживало сплит, еще вакуум надо подстроить и все такое... ну короче такая задача, не на вечер, и не для человека, который от постгреса знает бегло прочитанный мануал.
Ну ладно, допустим, я уволился, пошел на завод, а там тоже базенка, тоже постгрес, мастер с репликами и далее по списку. Собсно, громадный пласт админов тем и жил - и живет: винда одинаковая, между убунтой и центосью разницы ну не так, чтобы дофига, постгрес налево и направо одинаковый. Линукс- или виндоадмин везде одинаковый.
Амазон предлагает, что, товарищи, давайте в стиле "переиспользования кода" мы вам отдадим сразу кошерный постгрес с репликами, грамотно настроенные k8s, редисы там всякие с RabbitMQ - ну короче, чтобы вам не нужен был штат админов под то же, что и у всех, а чтобы ваши разрабы просто юзали это как сервис и не парились.

[beldmit]

Угу, понятно. Надо знакомых DBA поспрошать, как они конкретно воспринимают эту угрозу.

Спойлер: НЯП, на Amazon ты не можешь сам определять, какие контрибы ставить, например — то есть этот случай уже становится немного специальным...

[elglin]

Я постгрес как пример привел, сам я как раз человек с бегло прочитанным мануалом. Тут не только DBA; если посмотреть в экосистему Амазона, там и базы данных разных видов, и асинхронная коммуникация, и хранилища всякого вида, контейнеры сякие и этакие, есть своя колоночная база, свой мониторинг, лог-анализ и так далее. Короче говоря, если ты понимаешь в архитектуре приклада и чем его обмазать, и ты умеешь вот это на уровне юзера, то ты можешь собрать все это во что-то работающее без толпы админов. В принципе, это, возможно, и есть суть модного девопса, я встречал в англоинете плачи Ярославны про то, что я был админом, и я что-то знал и мог; а теперь я девопс с бОльшим ценником, но по сути я glorified Amazon operator, и это баттхерт.
Что до немного специальных случаев, то они занимают не такой большой процент, и, обычно, это контора, которая может позволить себе бородатого дядьку для обслуги базы, и не одного.

Ну и если убрать гонор, то многие конторы, надувающие щеки, что они энтерпрайз (как моя) на деле-то типичный верх SMB (Small & Medium Business), ну на крайняк погранично с реальным Enterprise. Просто щеконадуватели любят мыслить категориями конца 90-х, когда энтерпрайз начинался с пары стоек, а сегмент SMB с тех пор изрядно подрос. А для SMB как раз обмен локальных админов на "продвинутых операторов Амазона" выглядит тем, что доктор прописал.

[scif_yar]

>>И опять же, суть не в этом, а суть в том, что разработчик в кои-то веки можно полностью контролировать стек. И это прямо-таки офигенно.
-
И тут мы втыкаемся в то, что разработчик НЕ будет заниматься рутинными задачами по подвязке своего кода в Амазон. И будет заниматься чисто кодом.
Да, в ТЕОРИИ он может взять докер-ямл-етц, раскатать это все в облако и вася кот. И бекап настроить.
В практике человек который умеет все перечисленное И КОД - уже SRE.
НО
В практике системного администрирования (того, что так называется) все равно тонна задач. Ну ок, мы выкинули весь локальный аппаратный стек, у нас все в облаке. Прям вот совсем все, офис-365 кругом.
- сети надо
- рабочее заведение - удаление аккаунтов надо
- бекапы таскать туда-сюда надо (и бдить, что они есть)
- подбивать счета за это все надо. Это ж все не то что не бесплатно, а прям АПЩЕ очень так не гуманно стоит.

Ну и плюс регуляторка типа банки-клиенты, отчетность, ЛВС по зданию - вот это все надо.
То есть на инфраструктуре не замыкаемся.
С другой стороны инфраструктура наземная стала сильно, сильно проще. Мало скорости - взал all flash array (AFA), все равно мало - взял NVME. Не хватает постгри и 86 - взял ибм и сракел. Ну да, дорого. Но любой интегратор продаст это под ключ.

[elglin]

> В практике человек который умеет все перечисленное И КОД - уже SRE.
Об чем и разговор, что у нас исчезает админ и появляется системный программист на новом витке эволюции, который теперь называется SRE.
> сети надо
Датацентровская на амазоне и регулируется через их набор всего.
От офисной много не надо - у тебя есть стандартный конфиг, накатывающийся на свитч, и тебе пофигу. Никакого STP и прочих извратов не надо; максимум - закатать такой-то порт в такой-то влан. Итого у тебя есть мужик, который умеет в ансибль, и Вася на подхвате, при этом обязанности Васи - включить свитч, воткнуть в него кабели и звонить в поддержку, когда лампочки на свитче не горят. Ну или горят, но красные.
WAN интереснее - но опять же, VPN настраивается по темплейту, а если у тебя какой-нибудь Velocloud, то все сводится к предыдущему Васе: распаковать белую коробочку, воткнуть в нее проводочки, звонить по такому-то телефону, если горят красные лампочки или не горят зеленые.
> рабочее заведение - удаление аккаунтов надо
Мы ее, конечно, писали много месяцев, но у нас есть кривая и косая автоуправлялка ими. То есть Вася пошел на страничку, нажал на картинку, ввел в форму нужные поля и сел ждать, пока ему не напишут в почту, что все сделано. Если долго не пишут - стучаться в такой-то чатик.
> бекапы таскать туда-сюда надо
Сеекундочку. У тебя все валяется в Амазоне. Так и бэкапы там же. И это туда-сюда - это кроссрегионовая репликация S3. А что до бдить - так настроил нотифайки в SNS-топик и нарисовал watchdog, который поднимает тебе тикет, если сегодня нотифайки не было. Да и 15 лет назад это было, только через почту.
> подбивать счета за это все надо
Амазон сам присылает, а если ты нормально заморочился с тэгированием и посидел недельку с парсингом, то ты этот счет распиливаешь на то, за счет какого именно отдела и приклада наш безудержный праздник жизни (у нас оно есть, если что, кривое и косое, но есть и работает).
А что до остального - вот тебя прет с этой инвентаризации, амортизации и всего прочего? Меня вот настолько нет, что у нас бОльшая часть этого скинута на бухов; и я тебе больше скажу, чем меньше у тебя хозяйства на земле, тем меньше у тебя таких проблем. Больше всего секса с учетом и контролем ноутов, которые кто-то постоянно пытается проиметь или зажать - потому что проиметь двух-юнитовую железку массой килограммов на пятнадцать не то, чтобы совсем сложно, но сложнее.

То есть при грамотной организации труда ты кучу классических "сисадминских" вещей передаешь либо в SRE, либо секретарям, либо хрюшам, либо бухам, либо Васям-по-инструкции. А если мы говорим про 1С, банк-клиенты и прочую фигню, так для этого есть выделенный 1С-ник или прикормленный, прости господи, франчайзи. А если нет - ну честно, я вот никогда 1С не умел и никогда от этого на рынке труда не страдал. Поэтому не компетентен.

[scif_yar]

>>То есть при грамотной организации труда ты кучу классических "сисадминских" вещей передаешь либо в SRE, либо секретарям, либо хрюшам, либо бухам, либо Васям-по-инструкции.
-
Вот тут мы утыкаемся в организацию труда и прости госпдя ШТАТНОЕ РАСПИСАНИЕ.
Ты говоришь ужасные вещи с точки зрения УПРАВЛЕНЦА - скинуть задачи с отдела, значит урезпть штаты и косты.

[scif_yar]

>>От офисной много не надо - у тебя есть стандартный конфиг, накатывающийся на свитч, и тебе пофигу. Никакого STP и прочих извратов не надо; максимум - закатать такой-то порт в такой-то влан.
-
Ну как не надо. STP конечно не нужен, нужен bpdu guard это понятно. Но тебе все равно надо разбираться с тем какие вланы нужны, где сидят разработчики итд. То же самое никуда не девается при переезде в облако - все разделение васянов, что вот этому васяну (а даже и из дома) можно вот к этой группе сервисов, а вот этому - к совсем другой.
---
>>Сеекундочку. У тебя все валяется в Амазоне. Так и бэкапы там же. И это туда-сюда - это кроссрегионовая репликация S3.
-
Во первых оно надо хранить на земле или в другом облаке. Во вторых, реплика с задержкой не равно бекап.
---

В итоге если порезать классический админский стек "на земле" на куски типа электрика - инфра- СХД - сеть датацентра - инфраструктурные сервисы, то нижняя половина выкидывается в облако. Но
- сети все равно разграничивать надо, причем понимая что делаешь
- реплики заводить нужно, причем не далее-далее как ты скуль разворачивал, а понимая что каждый клик - деньги, и весьма немалые. Особенно если скриптом.
- и дальше на тебя вешают лычку SRE, cloud operator, и всех собак. Особенно когда облако (или канал до него, например от действий оператора, или росзабора) встанет раком. И ты такой а, чо?
И начинаешь считать кросс-клауд резервирование и тут совсем беда.

То есть выхватываешь ранее описанную проблему - стек сервиса ВНЕ твоей зоны контроля.

[elglin]

Стоп. Разве это не замечательные вещи: урезать штаты, задачи и косты? Покойный Альтшулер же утверждал, что идеальная система - это та, которой нет.
У нас же не советский колхоз, чья задача - не собрать урожай, а обеспечить работой всех деревенских алкоголиков.

[elglin]

> Во вторых, реплика с задержкой не равно бекап.
Батенька, ну я ж спецом написал про S3. Бэкап в локальный S3, а кросс-регионовая репликация - это аналог грузовика с ленточками, то есть срыв репликации S3 - это не "бэкап упал", а "ленты вовремя не вывезли". То есть пресловутое 3-2-1 тут соблюдается.
А про "на земле или в другом облаке" - я эту песню слышал еще когда виртуализацию внедряли 10 лет назад. Вкратце: к виртуализации облаку выкатывают требования, которым имеющееся физика хозяйство на земле не удовлетворяет.
> все разделение васянов, что вот этому васяну (а даже и из дома) можно вот к этой группе сервисов, а вот этому - к совсем другой
Это решают гомоинфосеки. А ты им дал тулзу, в которой у них можно что-то попросить, а они могут послать нафиг. А если вдруг разрешили, оно сделалось. Полгода ипаццо с SDK твоего файра, да, зато ручками в консоль ты лезешь потом раз в пятилетку. Окей, или купить задорага какое-то платное решение... и полгода ипаццо с его настройкой.

> стек сервиса ВНЕ твоей зоны контроля
Всегда останется, а абстракции всегда текут. Но в регулярном случае они не текут, а стек сервиса в регулярном случае работает. А в этом ключе как раз облака - это мощнейший инструмент угнетения народных масс деления экс-админов на тех, кто пишет тулзы инструкции для васянов... и васянов. Being Vasyan sucks moose balls.

[scif_yar]

>>Стоп. Разве это не замечательные вещи: урезать штаты, задачи и косты? Покойный Альтшулер же утверждал, что идеальная система - это та, которой нет.
-
Безусловно! И сдедать это надо путем доказывания начальству, что соседний отдел - мудака, и урезать надо их. А наши красавчиги и в мой департамент надо еще нанять людей и расширить штатное расписание

[scif_yar]

>> А ты им дал тулзу, в которой у них можно что-то попросить, а они могут послать нафиг.
-
И тут мы втуляем в то, что инфосеки не хотят заниматься рутиной, типа сходить к разрабам и выяснить откуда и куда и какой нужен доступ.
---
>>деления экс-админов на тех, кто пишет тулзы инструкции для васянов... и васянов. Being Vasyan sucks moose balls.
-
FAANG + MS и "остальные" да. Только методология FAANG и прочих хуяндексов вообще не ложится на другую часть кровавого энтерпрайза. Потому что отдать данные в облако == потерять данные. Скандалы с амазоном уже были, что они лезут куда не надо и угнетают.

[anonim_legion]

Пост хорошо состарился. Теперь с Амазоном уже не очень работается, если изнутри РФ.

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

[elglin]

Экий вы архивный пост раскопали.
Я бы сказал, не состарился вовсе. Технологически за два года ничего не изменилось - разве что в пользу облаков.
Все проблемы в нетехнологической части. То, что изнутри РФ не очень работается с Амазоном - что ж, проблемы 2% рынка шерифа не волнуют. Из Ирана, я думаю, с Амазоном тоже не работается, или с Кубы.
Про компании, не желающие ехать в Амазон, есть много соображений.
1. Я по нескольким всяким доморощенным салфеточным методикам считал, и каждый раз у меня Амазон выходил на 20-40% дороже своего хозяйства. Когда я это выкатывал уважаемым людям, никто из них не критиковал ни мои исходные данные, ни методику, хотя, чоужтам, хватало белых пятен. Все критиковали либо несогласие с генеральной линией партии, либо мой неучет пресловутых intangibles. Ну во втором случае тоже все понятно, intangibles можно считать как угодно и в любую сторону.
2. Я многократно видел ситуации, что в своем хозяйстве в пределах имеющихся (очень конечных) ресурсов их перераспределение невероятно быстро. А в теоретически бесконечных ресурсах облака есть соображение, что они все стоят денег, а потому каждый новый чих требует согласования бюджетного комитета, которому влом собираться иногда не то, что раз в неделю - раз в месяц. В итоге в теории облако повышает гибкость управления ресурсами, а на практике - понижает.
3. Ну и все соображения всякой там регуляторки, DSGVO, GDPR и прочих страшных аббревиатур никто не отменял, а их частенько куда как проще соблюсти и по букве, и, тем паче, по духу, на своем железе.

Иными словами, как говорил мой бывший начальник, и в чем я был с ним согласен, пресловутый "девопс" - он не в технологиях, а в головах. Нюанс в том, что по различным соображениям, как вполне рациональным, так и "из замшелости и лени" в головы девопс не проникает. Уж тем более в конторах, где 20% персонала заняты вахтерством, а еще 20% персонала изобретают методы против вахтерства, чтобы остальные 60% могли работать.

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