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

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

От этой точки и строится моя линия самообразования. Здесь (на Западе) никто не хочет, чтобы человек знал глубины одной конкретной технологии. Знание и широкая экспертиза целого стека или вообще одной большой платформы оценивается гораздо выше. Потому я и полез в Амазон (хотя душа лежит к 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 не помогут, пока мы сами не поймем природу проблемы и найдем в себе силы с ней бороться.

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

Между делом, хочу наконец научиться пользоваться голосованием в Телеграм. Давайте вместе протестируем. Про что больше писать?
🤖 - больше про технику
🤡 - больше про процессы и практики
👽 - больше про прочее

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

Удалось потрогать портал обучения от LinkedIn. Ценник у него такой же, как у Pluralsight, и меньше, чем у LinuxAcademy.
Из плюсов - огромный выбор курсов, в том числе и не связанных с ИТ. Дизайн, маркетинг, вот это вот все.

Из минусов - в основе обучения лежат видеолекции с небольшими лабами, которые качаются и делаются локально. Закрепленность знаний проверяется небольшими тестами, не дающими понимания, что полученная информация закреплена на практике. Но этим же страдает и Pluralsight.

Правда, открыл курс основ по веб-разработке и дизайну (совсем нулевый), и в первой же секции идет дубовое пояснение основ HTML, CSS и, простите, JavaScript.
Особенно раздражает, когда лектор с сияющими глазами говорит: “Да, это выглядит довольно сложно, но, поверьте, это очень легко!”
Вот… честно, не люблю таких преподавателей. Их мотивация понятна - им нужно стимулировать все больше новичков входить в сферу ИТ, но так не делается.

В последнем голосовании, люди 10 раз нажали на инопланетянина. Я позволю себе предположить, чтобы вы либо имеете косвенное отношение к ИТ, либо вам интереснее, когда я пишу про свои приключения с газовыми компаниями.

Но на всякий случай, если вы однажды захотите начать (или продолжить) карьеру в ИТ: неважно, какое направление вы выберете, будь то дизайн, разработка или системная инженерия - ИТ это НЕ легко.
Как и любая другая интеллектуальная деятельность, ИТ требует навыков и знаний, которые необходимо приобрести, прежде чем начать бороздить просторы рекрутинговых сайтов. Это не значит, что нужно бросать все и поступать в МГТИ имени Баумана, но придется инвестировать в себя деньги и время.

Любой, кто скажет вам “ИТ это легко” - лжец и подлец. “Гоните его, насмехайтесь над ним.”

Продолжаю играть с голосовалками. Опрос для ИТ спецов и всех, кто с ними связан.
Какого рода вы ИТ спец (разработка или администрирование)
- 😃 - если вы по Microsoft (Windows Server, Powershell, OctopusDeploy, etc).
- 😍 - если по Linux (RedHat, Ubuntu, bash, etc).
- 😳 - если оба.

Яндекс индексирует документы в Google Drive. Если у вас там что-то важное - убедитесь, что это хорошо спрятано за настройками приватности. Яндекс вроде это дело исправил, но береженого Бог бережет.

Ну и помним, что хранить пароли и явки где-то в облаке у Гугла - absolutely haram.

Теперь, когда мы поговорили о том, к чему пришел DevOps в наши дни, самое время написать о том, что полезного (помимо уже сказанного) он нам принес.

Компании стали применять DevOps по-разному. Те, кто уже использовал популярные framework’и Agile, например Scrum, поставили инженеров в “продуктовые” команды. То есть у вас есть команда - разработчики, тестировщики, инженеры. Поскольку Scrum подразумевает кросс-функциональные команды, на выходе мы имеем разрабов, которые немножко сисадмины, и сисадминов, которые немножко разрабы.

В целом неплохо, и такая модель хорошо работает, правда у нее есть и свои недостатки. Например, когда у вас продуктовая команда как вещь-в-себе, она пилит проект так, как ей удобно. Платформа, ОС, язык программирования, DevOps tools - все выбирается самой командой и строго под ее нужды. Если у вас много продуктовых команд, то вы получаете потрясающий бардак и зоопарк, где команда А уже сидит в Кубере с этими вашим докером, а команда Б все еще делает golden AMI в AWS во время релиза новой версии приложения. Сравнить KPI (а топы очень любят KPI) таких команд тяжело, поэтому проверить эффективность той или иной команды становится тем еще приключением.

Другие конторы, чаще всего крупный сектор с headcount в 5000+ человек и миллиардным оборотом, стали делать отделы - отдел FrontEnd разработки (их может быть много), Baсkend разработки (тоже может быть много), отдел инфраструктуры и, простите, отдел DevOps.
Вроде silo - все сидят в своих уголках и что-то там делают. Взаимодействие уже не такое шустрое, люди могут сидеть в разных офисах, если не городах или странах - сложно просто подойти и поговорить ртом. Но и такой подход имеет право на жизнь, и вот почему.

Когда вы инженер в DevOps отделе, вы “поддерживаете” разработчиков. В ваших интересах, чтобы разрабы спокойно и без лишних проблем выкатывали новый код в production, а вы, если что, быстро его откатите обратно. Если вы инженер инфраструктурного отдела (допустим у вас в 2018-ом до сих пор свой ЦОД), то вам нужно, чтобы серверы и сеть работали без перебоев.
Такие потребности позволяют создать сервисно-ориентированные команды. Infra-команда не предоставляет железо - она предоставляет сервис, где каждый может “заказать” себе виртуалку. DevOps команда не предоставляет тулзы - она предоставляет сервис для управления приложениями.

Поскольку такие команды обладают бОльшей экспертизой в инструментарии, нежели сами разработчики, то они дают им один инструмент под определенную задачу, например, Puppet/Ansible/Chef для управления серверами, Terraform/Cloudformation для создания новых ресурсов, Jenkins/Teamcity для CI/CD, Github/Gitlab/GitUNameIt для хранения исходников, ну и всякие Linter’ы и прочие финтифлюшки. У разрабов особо нет выбора, и они пишут приложения, придерживаясь каких-то общих, зачастую навязанных административным ресурсом, стандартов.

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

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