Проблема третья - узкий кругозор.

Когда вы окружаете себя недвижимым и в то же время хрупким монолитом, вы тратите свое драгоценное время на удержание этого колосса на глиняных ногах. В результате стек технологий сокращается до количества пальцев на одной руке - осваивать новое попросту нет времени.
Ребята в западных конторах давно это поняли и инициировали движение всеобщей автоматизации (и к счастью русские ребята тоже это поняли и теперь двигают прогресс в СНГ), где инженер тратит 40 минут на автоматизацию развертывания “ЧЕГО-ТО”, когда он это “ЧЕГО-ТО” поднимет руками за пару минут. Западный бизнес относится к этому с пониманием, ведь автоматизация не только сокращает время развертывания бОльшего количество серверов в будущем, но и снижает риск отказа по причине человеческого фактора.

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

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

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

Ну теперь о самом последнем, но не менее важном.

Большинство инженеров любит свою работу - и это нормально - что иногда приводит к интересным последствиям.
Давным давно я писал о блогерстве инженеров, как своего рода портфолио (t.me/manandthemachine/68). Что я заметил, западные инженеры пишут блоги про “трендовые” вещи, как serverless, контейнеры и облачные вычисления. Зачем они это делают? Ну как минимум это дает им возможность “потрогать” все самое новое (а вы помните, что в западных конторах с бюджетом все хорошо), но и как бы показывает всему миру: “Посмотрите на меня, я тут весь такой продвинутый”. У русских блогеров ситуация немного другая. Видите ли, западный блогер напишет пост про то, как он потрогал какую-то штучку (поверхностно), покажет пару полезных команд, но в целом его пост будет состоять из воды. “Как это можно было бы применить в продакшоне”. Исключение, конечно, составляют профессиональные блоги, такие как блоги на сайте AWS - там часто описывают важные use case’ы, например, как удаленно выполнять код на ЕС2 из Lambda.

Когда открываешь русский блог, будь то Хабр или чей-то Telegram в паре с Telegra.ph, ты видишь хардкорное инженерное исследование. Один из таких ребят (и это не реклама) некий Артем с его каналом “Записки сисадмина” (https://t.me/SysadminNotes) - человек не только делится полезными ссылками, книгами и видео, но и расписывает разные решения тех или иных проблем.

То есть, я повторюсь, русский инженер самый сильный (и под русским я подразумеваю каждого, кто говорит по-русски - ребята из Украины и Белоруссии не обижайтесь). Не потому что он самый умный, а потому что самый упорный.
Русский инженер, столкнувшись с проблемой, которая не гуглится, начинает лезть в подноготную и ковырять. Ковырять долго и упорно, разбирать на винтики, делать реверс-инжиниринг и до тех пор, пока не решит проблему. Потому что он умный. Он любит свою работу. Ему ИНТЕРЕСНО. Ему это НРАВИТСЯ. И именно в этом и кроется проблема.

Я уже говорил, что хороший инженер работает эффективно. Эффективность измеряется не только в надежности и производительности решения, но и во времени - насколько быстро инженер его применит. Когда же человек тратит титанические усилия по инжинирингу и хакингу чего-то, он фокусируется на этом. И настолько, что забывает про аналоги (вспоминаем про узкий кругозор). Он не видит, как любят говорить в Нидерландах, bigger picture.

Русский инженер (правда, не могу говорить за всех) трудолюбивый. Он будет долго и скурпулезно решать задачу, но в итоге проиграет, потому что конкуренты решили не заморачиваться и сделали это через managed service (не путать с аутсорсингом). Да, они до конца не поняли, как там все устроено, но это уже и не важно - не их проблема. Работодатель в итоге не успевает за конкурентами, огорчается и начинает думать, что нанятый инженер не так уж и хорош. Инженер с этим не согласится (ведь он так круто все сделал), но отношения уже испорчены.

В итоге человек пишет пост про то, как сделать Х в У, чтобы получилось Й, а оно и никому уже и не нужно (потому что есть Амазон, Гугол, CDN и так далее), и пострадает при этом его работодатель и он сам.

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

Потому что в итоге выяснится, что достаточно было создать бесплатный аккаунт на Cloudflare и ваш сайт защищен от DDoS, и не стоило так заморачиваться с конфигурацией маршрутизаторов, фаерволлов и прочего.

Исключение составляют люди из R&D. У них работа такая - ковырять, изучать, хакать, писать исследовательские отчеты.

Когда я потратил 3 месяца на исследование создания DC/OS кластера с помощью Terraform, чтобы обеспечить возможность in-place upgrade, и обнаружил, что Fargate теперь есть eu-west-1, я, честно говоря, очень расстроился. Я был уверен, что получу жесткую критику в свой адрес за долгую работу, но вместо этого получил задачу исследовать proxy & service discovery для DCOS. И заодно посмотреть, можно ли переписать Terraform stack под Cloudformation (мы все же склоняемся к нему как IaC тулзе). А про in-place upgrade сказали и не париться. DC/OS слишком хрупкий, пересобирать на лету продакшон очень рискованно. Проще и безопаснее собрать новый кластер и перетащить приложения на него. Да и навыки Cloudformation по мнению руководства важнее, тем более если мы в скором времени перелезем на Fargate.

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

Зайдите на Гитхаб вашего любимого проекта. Зайдите на StackOverflow. Посмотрите с чем люди столкнулись. Посмотрите какие созданы issue. Напишите патч, создайте Pull Request. Если обнаружили что-то сами и не знаете как решить - напишите в issues или заведите тикет в JIRA проекта.

И конечно же пишите. Пишите блоги, заводите каналы, делитесь, обсуждайте, ходите на митапы, задавайте вопросы, отвечайте на вопросы.
Глядишь, такими темпами не только Яндекс, Мейл.ру и Рамблер будут двигать индустрию на постсоветском пространстве.

Судя по слухам Микрософт купил GitHub.

Ну привет....

Не то чтобы я против Микрософта, мне очень нравится их политика в последнее время. Чего только стоит dotnet на Линуксе и поддержка bash в Windows 10.

Однако это то, что касается разработок Микрософта. Когда речь идет о поглощении других компаний, результат как правило удручающий.

И если я могу забить на то, что случилось с LinkedIn (а это случилось бы рано или поздно даже без участия МС), то Нокию я им никак не смогу простить.

Смотрите, я не претендую на истину в последней инстанции (касательно своих постов про “плохих” инженеров из России и СНГ).

То что я видел в России, я вижу и здесь.
Разумеется, каждый человек сам выбирает свой путь. И если ему нравится заниматься тонкой настройкой вебсерверов и придумывать оркестрацию на коленке - ну кто я такой, чтобы ему это запрещать.
Разница лишь в том, кем человек видит себя в будущем. Лично я, после нескольких лет саморефлексии, решил - мерилом моих знаний является размер компенсации (считай денег). Проще говоря, чем больше денег - тем больше я реализовал свой потенциал. И все эти сертификаты, нетривиальные задачи и выполнение своей работы направлено только на получение бОльшего количества денег, чем у меня есть сейчас. Естественно, у каждого специалиста есть свой потолок, поэтому думать надо и о карьере. Финишная черта лично для меня - технический директор. В обозримом будущем - тимлид или главный архитектор. На худой конец - консультант на фрилансе.

От этой точки и строится моя линия самообразования. Здесь (на Западе) никто не хочет, чтобы человек знал глубины одной конкретной технологии. Знание и широкая экспертиза целого стека или вообще одной большой платформы оценивается гораздо выше. Потому я и полез в Амазон (хотя душа лежит к OpenStack). И потому я и сохраняю свое время и не лезу в Kubernetes (хотя он в моем списке “на изучить”). Время не пришло. Выхлопа нет.
Ни Кубер, ни Опенстак не принесут мне ни в долгосрочной, ни в среднесрочной перспективе материального благосостояния, а значит мне не стоит тратить на них время.

Мало того, Запад все больше делает уклон на “мягкие” скиллы - коммуникабельность, работа в команде, навыки презентаций, даже, прости Господи, навыки продаж. Местные конторы поняли, что нет смысла гоняться за технологиями. Отдать их на откуп платформе, где специально обученные люди делают это за тебя в результате проще и дешевле. Те же, кто это еще не понял, либо начинают осознавать, либо уже в процессе миграции.
От того и грустно, что “дома” народ продолжает все делать на коленке. Особенно потому что “прикольно потрогать”.

Конечно, бесконечное развитие ИТ приведет к тому, что и мы (инженеры, разрабы и т.д.) останемся без работы. Но до этого еще минимум лет 10, если не больше.
А пока нас не убрали от кормушки, давайте зарабатывать себе на золотой парашют.

Вот и перевалили рубеж за сотню. Очень круто!

Мне понадобится некоторое время, чтобы придумать для уважаемой подписоты новый контент.

Так что если у вас есть идеи - пишите в личку.

А вот и повод для контента прилетел.

Спасибо @volarenege за ссылку на прекрасную статейку. (https://habr.com/post/413819/)

Цитировать её не буду. Если у вас есть свободные 15-20 минут, то чего уж птичек из катапульт пускать - почитайте как у человека не бомбит.
Что интересно - похожие вещи я видел (и вижу) на западном рынке труда, но об этом по порядку.

Касательно “плюшек” в виде комфортного рабочего места, кофе, печенек и крутого компьютера. Просматривая вакансии на Stackoverflow Jobs я не раз находил вот такие “плюшки”:
- Зарплата выше средней по рынку (и это прямая цитата)
- Рабочий Макбук (как показатель статуса и крутости компании - “смотрите на нас, мы можем позволить себе тратить больше 5к евро за рабочее место”)
- Дополнительные отпускные дни (конкретно в Нидерландах). По закону работнику полагается 20 рабочих дней отпуска. Большинство контор добавляет еще 5 (типа от себя), тем самым привлекая людей своей особенностью. О том, что так поступает 90% работодателей почему-то игнорируется.
- Молодая амбициозная команда (тут нечего добавить)
- Скидки на медстраховку. В Нидерландах работодатель не имеет права (налоговая не разрешает) полностью оплачивать медстраховку. Поэтому те же пресловутые 90% компаний заключает контракт с одной или несколькими страховыми, которые предоставляют сотрудникам скидку до 10%.. Самое обидное, что экономия составляет дай Бог 20-30 евро в месяц на человека.

Про поведение компаний:
- Нытье про нехватку хороших кадров. В Нидерландах то же самое, крупные конторы (особенно банки и электронная коммерция) наперебой пишут в свои (и не только) блоги, что очень сложно найти достойных кандидатов, поэтому те, кто может себе позволить, нанимают людей из-за рубежа (собственно, я так сюда и переехал). Те кто не может - нанимает местных ПТУшников и много тратит на их обучение.
- Пассаж про СберТех просто бриллиантовый (я честно не знал об этом). В Нидерландах тоже есть такой случай, и называется он Philips. Philips нужно было нанять больше разрабов, причем срочно, и на встрече с рекрутерами им сказали - крутые разработчики и инженеры хотят много денег. Philips поступил очень просто - стал брать сеньоров с ЗП от 100к евро в год (для Нидерландов это очень крутая зарплата). Остальные конторы, особенно пережившие digital трансформацию, плакали, давились, но тоже стали поднимать ЗП. Если раньше “хорошая” зарплата в ИТ была в 60к евро в год, то теперь этот порог поднялся до 75 тысяч.

В статье еще про культуру разработки, но я об этом завтра напишу (хочу вчитаться хорошенько).

Немного оффтопика пожалуй (канал и про жизнь все-таки).

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

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

Можно сравнивать зарплату ИТшника в Новосибирске с зарплатой польской уборщицы в Германии. О том, что уборщица платит больше налогов, никто не хочет думать. Скучно.
Можно также вспомнить про сумасшедшую ювенальную юстицию, где чиновники забирают детей из домов по надуманным поводам и держат их в специальных детдомах. Опустим всю трагичность истории и сфокусируемся на том, что детдома в Нидерах коммерческие, и за одного ребенка там зарабатывают, кажется, где-то 35 тысяч фунтов в год (https://www.telegraph.co.uk/comment/columnists/christopherbooker/10092748/Dutch-social-workers-catch-the-English-disease.html). Follow the money, как любят говорить мои друзья.

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

Для экспатов, которые шибко умные да еще и с дипломом, существует налоговая льгота, так называемый 30% рулинг. Он довольно простой - если вы удовлетворяете определенным требованиям, то ваш работодатель запустит определенную процедуру, после которой 30% вашего дохода не будет облагаться налогом. Это крайне полезная вещь, и дается она (пока) на 8 лет. Считается, что за 8 лет человек успеет решить, хочет ли он отбросить в Нидерландах корни, возьмет жилье в ипотеку, снизив свои расходы на жилье где-то так в 2 раза, получит гражданство и на правах полноценного бюргера будет в стране жить. Со всеми налогами, пенсией и правом голоса.

В апреле МинФин предложил снизить срок льготы с 8 до 5 лет. Предложил он это еще в прошлом году, но в апреле его все же услышали, и Нижняя палата Парламента подписала этот план. Теперь в сентябре на планировании бюджета его рассмотрит еще раз Верхняя палата Парламента. Если это предложение будет принято, то с 1 января 2019-ого года люди будут пользоваться льготой на 3 года меньше.

Но это не самое страшное - льготу уже понижали с 10 до 8 лет, и это всегда было проблемой “новых” экспатов. Самое страшное, что предложение имеет ретроспективный эффект. То есть те люди, у которых УЖЕ есть рулинг, тоже попадают под сокращение. Мой рулинг изначально до 2024 года. Если изменение примут, то он будет до 2021.

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

С другой стороны, обиженные экспаты собрали больше 25 000 подписей петиции, около 10 000 евро пожертвования на адвокатов и даже пару раз выступали на митингах перед парламентом в Гааге. Так что я лично держу кулачки, чтобы все у нас было хорошо.

Продолжим вчерашнюю тему (Статейка на Хабре, покрутите чуть наверх).

Автор, немного расстроившись ситуацией на рынке, продолжил тему культурой разработки.
Первое, что бросается в глаза - отношение к так называемым энтузиастам и их попыткам писать свои собственные OpenSource решения. Дескать, у людей нет времени заниматься этим дома, а контора это дело поддерживать не берется.
Что тут можно сказать? Сами OS репозитории на Github я делю на 3 категории:
- Личные маленькие проектики. Такие обычно разрабы пишут не только для себя, но и для своего имиджа. Все-таки Github лучше тестовых заданий показывает на что способен человек (и я об этом уже писал https://t.me/manandthemachine/56)
- Большие организационные проекты - Jenkins, Linux и прочие. Тут добавить нечего.
- Корпоративные проекты - от контор типа Netflix, Facebook, Telegram и Amazon. Вот это, пожалуй, то место, где энтузиаст может почувствовать себя “нужным”.

Однако большие компании пишут свои собственные разработки не для OpenSource. Бывает такое, когда конторе “не хватает” доступных на рынке решений. Тогда контора собирает этакий Task Force из высококлассных инженеров и начинает пилить свой продукт. В момент, когда разработка принята на борт, принимается решение выложить ее на Github. Здесь два плюса: имидж компании и возможность пользоваться “бесплатным” трудом энтузиастов через Pull Request’ы.
Так что когда вы увидите, как Фейсбук переводит свой балансировщик в OpenSource (https://github.com/facebookincubator/katran), отнеситесь к этому чуть-чуть критически. Но вернемся к статье.

Далее автор пишет про некий “хейт” по отношению к энтузиастам. Вот цитата:
“Однажды я спросил одного менеджера одной известной компании, что он думает по этому поводу, и он ответил: “Я знаю много изобретателей, которых взяли на работу, потому что у них есть какой-то интересный продукт, который не имеет практического применения прямо сейчас. Это происходит везде во всем мире.” И далее добавил: “Просто мысль, которую вы говорите, категорически неправильная. Потому что если ты изобретатель, которого нужно поддерживать, который не может поддерживать себя сам, то не нужен такой изобретатель”. Мне видится здесь прямой отказ следовать общемировым традициям. Якобы, талант найдет себе дорогу, и его надо воспитывать по “бразильской системе”, и ни о каком сотрудничестве с ним не думать.”

Вот тут тоже небольшое лукавство. Конторы, которые нанимают инженеров и разработчиков в feature teams, действительно не заинтересованы в том, чтобы эти люди тратили рабочее время (и деньги фирмы) на написание “своего” софта. Конторы же, которые это практикуют, имеют R&D группы для подобного рода экспериментов. Я уже писал, что R&D это очень дорогое удовольствие, и не только лишь все могут себе это позволить. Но в одном автор прав, не каждая технология может быть монетизирована. (Ну вообще можно продавать поддержку и тренинги, но это тоже требует вложений).

Дальше автор пишет про зависимость компаний от допотопных решений, дескать искать новых исполнителей проще. Лично мне это кажется вполне логичным, особенно в условиях НЕ ИТ бизнеса. Зачем им осваивать бесконечный поток новых технологий, платформ и стеков, если их основной доход завязан на производстве плюшевых игрушек или продаже цветов?
Единственный способ протолкнуть свою идею или точку зрения это “продать” ее. Посмотрите на это со стороны компании. Попробуйте “посчитать” сколько времени и денег понадобится на ее внедрение. Что это принесет?

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

Автор твердо заявляет, что это полный “харам” и расписывает “дозволенные” методики, такие как: систему грейдов (очень распространено в больших компания с headcount’ом выше 2000 человек), дедовщина (О_О) и понижение значимости разработчиков (О______О).

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

Ну и напоследок.

Дорогой подписчик, позволь предложить тебе маленькую мантру, которая поможет тебе найти себя, свое место в этом мире и познать дзен.
1. Цель коммерческий организаций - заработать максимум денег.
2. Коммерческие организации говорят языком цифр.
3. В текущих реалиях мира все решает баблишко.
4. Вокруг нас очень много мудаков, и среди них надо жить (ну или улетать на Марс вместе с Илоном)

Большое спасибо Артему из @SysadminNotes за рекомендацию.

Мальчики и девочки, я ухожу в оффлайн на 2 недели.
Если у вас есть какие-то идеи и пожелания - пишите в личку @ThomasStorm или на ящик thomas.storm@pm.me

Всем любви и увидимся в июле.

Отпуск это конечно офигенно, но вас, ребята, стало довольно много (внезапно) и игнорировать вас тяжело, да и не хочется.

Поэтому писать я хоть немного, но буду.
Также немного изменится формат ведения канала. Я заметил, что вы неочень активно мне отвечаете, поэтому будет так - когда у меня появится парочка идей, я буду пилить небольшое голосование (как только научусь это делать - я в телеге тот еще нуб).

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

Оставайтесь на связи.

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

В институте я узнал, что главная цель компаний - зарабатывать деньги. Это был первый звоночек.

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

Дальше были первые ИТ курсы, увольнение из Рено, устройство в Аспект, Украина, Крым, девальвация, кризис, закрытие офиса в Москве, переезд в Нидерланды и очередная смена работы - все эти истории вы и так знаете.

А после был Ловел фон Урле - хорвато-голландец, открывший мне увлекательный мир follow the money. Если я только-только начинал понимать, что миром управляют старые и жадные кретины, то Ловел в этом был уверен (и потому активно лез в биточек). Это был второй звоночек.

И если Леха открыл мою внутреннюю «темную» энергию, благодаря которой я быстро учидся и эффективно работал, то Ловел направил ее в нужное русло. Эти двое бы подружились.

Третьим и последним звоночком стала смерть Лехи.

Что же получилось в итоге? Тебе говорят, что конторы хотят денег, один твой друг говорит тебе, что надо пахать, а другой - что надо пахать ради денег. В финале тот первый друг погибает при непонятных обстоятельствах, оставляя тебя с острым чувством несправедливости.

Потом ты читаешь книгу Маркова «Хулиномика» и Мэнсона «A subtle art of not giving a fuck», чтобы понять почему вообще все так по-дебильному, а потом наступает волшебная осознанность.

Смотрите, я не претендую на роль всезнающего мизантропа. И уж тем более не считаю себя главным страдальцем на свете.

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

Я ловил себя на мысли, что я не хочу быть счастливым. Я хочу быть как мистер Вульф, хочу решать проблемы и «pretty please with a sugar on top».

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

Пока Остапа не понесло, давайте вернемся к основной теме канала.

Мне недавно написал один из подписчиков, и среди прочего была просьба написать свое мнение про DevOps. Некий известный инженер-сетевик утверждает (пруфов на руках нет), что код стад хуже, любой фиговый коммит идет сразу в прод и так далее.

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

В “далеком” августе 2008-ого 2 парней на конференции в Торонто впервые в истории произнесли слово DevOps. Сейчас этой практике почти 10 лет, и я думаю, самое время поговорить о том, во что превратилась эта культура, и что нас ждет дальше. Но сейчас чуть-чуть назад во времени.

Давным давно, когда главными инструментами сисадминов были bash и python, а общение между разработчиками и инженерами велось через системы управления проектами и тикеты, обновление приложений было неприятным и долгим процессом. Разработчики писали новый код, тестировщики прогоняли по нему тесты, а инженеры в ограниченный промежуток времени, именуемый maintenance window, выкатывали новую версию. Код не всегда работал как задумано, инженеры ругали разработчиков, разработчики ругали инженеров, проблема не на нашей стороне, вот это вот все. В последствии люди стали кое-как автоматизировать свою работу, кто-то делал это на коленке, изобретая велосипед, кто-то написал и стал продавать Hudson (папа Jenkins’а).

По сути, что тогда, что сейчас, проблема одна - разработчики просто хотят писать код, а инженеры просто хотят, чтобы оно работало. В итоге люди поняли, что так “оно” работать не может, и придется “дружить”. Так и появился DevOps - культура, в которой инженеры и разработчики работают вместе.

Как бывает с каждый новшеством, DevOps столкнулся с большой проблемой - его никто не понимал.

Во-первых, ИТшники обнаружили, что они “уже” делают DevOps - у них есть автотесты, CI (между прочим, этот термин впервые появился в 1991-году), автоматизированное развертывание и даже управление конфигурациями (самый старая тулза, насколько я знаю - CFEngine, релиз которого состоялся аж в 1993-ем, и им до сих пор пользуется IBM).

Во-вторых, управленцы решили, что DevOps это отдельная роль (и это, пожалуй, самое главное заблуждение), и стали искать под это дело DevOps инженеров, с 5+ лет опыта. Это было на минуточку в 2009-ом, когда культуре еще не исполнилось и года.

Однако были и те, кто понимал суть DevOps (это в основном были те, кто его и придумал) и пытались его адаптировать.
С тех пор особо ничего не изменилось, люди до сих пор ищут silver bullet, “правильный” DevOps, а на сайтах поиска работы до сих пор присутствуют вакансии DevOps инженер. Но это, как я думаю, нормально и врядли изменится.

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

Разработчики впервые начали смотреть на приложение с точки зрения админа - оно может ломаться, оно будет ломаться, и надо написать его так, чтобы оно “чинилось” как можно скорее (SRE) . Инженеры же пытались придумать, как можно описать настройку сервера в одном файлe (и желательно не в Bash скрипте), чтобы не ходить руками на каждый сервер (Infra-as-Code), да чтоб его еще и протестировать можно было.

Все это требовалось, чтобы превратить 3 отдела (Dev, QA, Ops) в одну структуру, работающую как часы. Вдохновленные историей про 10 релизов в день, люди стали придумывать разные методы достижения этой цели. Выделились 2 аспекта: технологический и организационный.

Что касалось техники, то тут все было более менее просто. И у инженеров, и у разработчиков уже были необходимые инструменты для работы, оставалось только их “подружить”. Так, например, инженеры стали хранить свои скрипты в системе контроля версий, а разработчики отправлять логи не локально, а на централизованное хранилище (как logstash). Стали совершенствовать мониторинг приложений с помощью отправки метрик, выделять конфиги приложения и держать их в отдельном месте, добавлять в приложения API для проверки работоспособности.
Микросервисная архитектура позволила упростить релизы и ликвидировать центральную точку отказа. CI/CD автоматизировал полную цепочку от коммита до развертывания в staging (а иногда и в prod). Amazon и прочие облачные провайдеры становился все популярнее, вышел Docker, а вслед за ним Kubernetes и Mesos, популярные сервисы для разработки Jira, Slack, Github и т.д. стали теснее интегрироваться друг с другом - медленно, но верно, наступала технологическая ИТ утопия.

С организационной точки зрения дела шли чуть похуже. Не смотря на то, что DevOps подразумевал совместную работу 3 разных ролей, большинство контор формировало отдельные группы DevOps - специалистов, отвечающих за весь спектр DevOps инструментов.
Такой подход не только не помогал, но и мешал: главной целью DevOps было уничтожить так называемые “silo” - роли с ограниченным доступом и зоной ответственности. Хуже всего было то, что разработка и эксплуатация не всегда могли “синхронизироваться” из-за разных методов управления проектами. Если разработка была проактивной и пыталась “доставить” определенный функционал за “спринт”, то Ops оставался реакционным и реагировал на входящие тикеты от разработки, по сути превратившись в helpdesk для разработчиков.

Софт доставлялся все быстрее. Аппетиты бизнеса росли, и если “хорошие” топ-менеджеры (насколько топ-менеджеры могут быть хорошими) стали использовать возросшую производительность для занятия своей ниши на рынке раньше конкурентов, а освободившиеся ресурсы разработчиков выделить на R&D или другие проекты, интересные самим разработчикам, то “плохие” (читай почти все) стали радостно резать расходы, оставляя минимальное количество людей для работы над проектом, используя освободившийся бюджет под маркетинг и продажи.

DevOps несомненно помог многим проектам, но его развитие совпало с общемировым повышением спроса на ИТшников. Люди не из сферы ИТ решили попробовать что-то новенькое (а тут на радость пришел JS с миллионом фреймворков), и на рынок пришло очень и очень много разработчиков с 3 месяцами работы. Чуть позже, с развитием DevOps направления, на рынок пришло такое же количество DevOps инженеров, которые знают, как написать Ansible playbook, но не знают, что такое load average.

Как я уже сказал, это ожидаемо, естественно и даже хорошо. Но проблемы, которые были у DevOps (точнее у людей, которые его пытались применять) никуда не ушли. Люди считают, что у них DevOps, потому что они проводят много встреч, а новому человеку выдают ноутбук с предустановленными IDE и Slack. Другие считают, что у них DevOps, поскольку они используют Kubernetes. У третьих, потому что разработчики имеют root доступ на серверы.

Лучше всего все беды DevOps, сам того не замечая, описал Дмитрий Столяров из Flant (https://youtu.be/CgCLPYJRxbU). “Если вкратце, мы занимаемся DevOps’ом. Давайте по-простому, внедряем Kubernetes.”
И никто не спрашивает, а нужен ли клиенту Кубер в принципе, если у них админ никак не сделает удобную морду для развертывания разработчикам, а разрабы никак не начнут отправлять метрики приложения в мониторинг.

В чем-то сетевик-пессимист прав. Качество кода упало. Некачественный код все чаще попадает в production. Но виновата ли в этом культура?
Обвинять DevOps в том, что код резко стал плохим, это как винить поп-музыку за то, что у нас есть Ольга Бузова и “Розовое вино”.

У нас (у ИТшников в целом) есть очень много проблем, которые нам надо решить, чтобы делать свою работу хорошо. Никакие системы, тулзы, провайдеры и DevOps с Agile не помогут, пока мы сами не поймем природу проблемы и найдем в себе силы с ней бороться.

В будущем все у нас будет хорошо. Но об этом я напишу чуть позже.