Немного оффтопика вам в ленту.

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

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

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

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

Другой сериал, который похожим образом запал в душу - новая криминальная драма "Озарк" - история финансового консультанта, сбежавшего в небольшой городок в штате Миссури, чтобы (сюрприз!) спасти себя и свою семью от казни бензопилой.
Главный герой Марти Бёрд тоже не дурак. Он "шарит в теме", всеми силами старается избегать рисков и делать все нормально и по закону. Однако в его схеме и структуре столько движущих частей, что раз за разом его попытки сделать все правильно, ломаются о несчётное количество черных лебедей.
Здесь вам и реднеки-героинщики, и нарко-картели, и налётчики-рецидивисты, думающие по модели "дать по шапке и забрать деньги".
Хуже всего, что ГГ начинает втягивать во все это свою жену и детей.

В целом оба сериала рекомендуются к просмотру детям старше 12 лет (наркотики это плохо, всегда) и ИТшникам (как ни планируй архитектуру, инфраструктуру и процессы, всегда найдутся идиоты, которые все превращают в прах и говно).

Навеяло сегодняшним постом в AfterTimes (t.me/theaftertimes/3498).

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

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

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

Я не люблю, когда контору называют галерой. Еще больше я не люблю, когда считают, что в конторах в Европе и за океаном, процессы построены лучше, чем в РФ.

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

По сути, в западных конторах сейчас семимильными шагами идет болезнь под названием “диверсификация”. Она может быть гендерной, может быть этнической, но ее суть проста - разбавляем клубок белых привилегированных мужчин людьми другого цвета и пола. В Нидерландах это пока на зачаточной стадии - тут нанимают женщину на должность финансового директора и потом хвастаются, что соотношение мужчин и женщин уже не 0 к 10, а 1 к 9. Прогресс! В Америке с этим и то хуже - нанимают не по достоинствам, а по параметрам, определяемым при рождении. Эти же кадры потом делают свой вклад, за счет проталкивания “веганского четверга”, а продукт как писали цисгендерные членомрази, так и пишут.

Но если спуститься чуть ниже на уровень обычного среднестатического офисного жителя, то тут у нас стандартные проблемы: чайка менеджмент, панический страх перед ответственностью, неумение планировать чуть дальше чем на 2-3 месяца вперед, и, разумеется, неумение внедрять практики и фреймворки Agile и DevOps.

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

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

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

С чего вообще это все началось: главный посыл (и это очень любят проталкивать безумные адепты диверсификации), что не стоит упускать талантливого сотрудника только потому что "он/она не такой как все". Если к вам на собеседование пришел выпускник MIT, то какая разница, с кем он любит спать, или какой у него цвет кожи.

Как убедить человека забить на свои бессмысленные принципы? Заставить его ими поступиться административно (через аудиты, штрафы и прочие коммерческие кошмары).

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

Почему произошел Black Lives Matter? Потому что черным американцам надоел полицейский произвол, а Майкл Браун просто стал последней каплей, даже не смотря на то, что его убийство было обоснованным (а как вы поступите, если на вас несётся огромный черный танк под наркотой, намереваясь забить вас до смерти?).

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

Это вовсе не означает, что расизма нет. Он есть: полицейский, черный, белый и бытовой.
Есть и сексизм. И гомофобия.

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

Конечно забавно, что чёрное рабство закончилось 200 лет назад, а образ "женщина=кухня" отсутствует лет так 20, но мы все ещё пережевываем одно и то же.

Будто других проблем в нашем мире нет. (Смотрит на охеревших банкиров и страховщиков)

Этот вопрос мне как-то задали на собеседовании. Когда я рассказал, что можно использовать стандартную библиотеку, интервьюер был в шоке - у него на бумажке правильным ответом было “использовать dd”.

✏️ chmod 000 /bin/chmod

# /bin/chmod 000 /bin/chmod

# ls -la /bin/chmod
----------. 1 root root 58584 апр 11 06:35 /bin/chmod

# /lib64/ld-linux-x86-64.so.2 /bin/chmod 755 /bin/chmod

# ls -la /bin/chmod
-rwxr-xr-x. 1 root root 58584 апр 11 06:35 /bin/chmod

На случай важных переговоров, собеседований и всякого такого. (Не повторять на проде просто так!)

#bash

Пришлось мне поковыряться с Graphite. Задача была простая, был Graphite запущенный в единичном контейнере на отдельном хосте с открытыми портами, и нужно было это чудо утащить в DC/OS, сохранив все метрики. Вроде бы ничего сложного - настроить persistent volumes, поднять приложение, скопировать старые метрики, перенаправить приложения, whisper-fetch, и все!

Вдоволь намучившись, но таки победив, я нарвался на главный косяк - Graphite в связке со Statsd использует UDP порт для приема метрик. Наши приложения используют как раз его (чтобы краткосрочный отказ Графита не ломал нам все приложения). Но вот беда - на рынке (да и в Гугле) не существует балансировщика со встроенным service discovery, чтобы обрабатывать входящие UDP дейтаграммы и отправлять их в нужный task.
Ставить статичный порт напрямую на хост, говоря task’у запускаться только на этом агенте - харам (Чего я больше всего боюсь? Что сервер сдетонирует и будет потерян навсегда). Попросить разработку переписать отправку метрик на TCP тоже не вариант - TCP балансировщиков внезапно ТОЖЕ нет!

Единственный адекватный вариант - уехать с Графита подальше (в сторону того же DataDog), забыв этот overengineered ад как страшный сон и живя дальше. Дорого, долго, народ не согласится.

Что делает ваш покорный слуга? Делает очень мерзко и некрасиво, поднимая это чудо на отдельном EC2. Чувствую себя грязным после такого.

Идея для домашнего проекта - написать небольшой балансер на базе Nginx, который мониторит Marathon и делает reload веб сервера, если контейнер отвалился и поднялся с новым портом.

Нарвался вот на такой блаженный пост на Хабре: https://habr.com/post/425413/

Если вкратце - какой-то западный человечек сдетонировал от комментария Нетфликса “Мы не нанимаем младших специалистов” и разродился тирадой на эту тему. Другой человечек разродился ответочкой. Люблю такое по пятницам после обеда. ^^

Я прекрасно понимаю компании, которые нанимают молодняк. Я прекрасно понимаю компании, не нанимающие молодняк. Здесь как в казуальных гоночках серии Need For Speed - можно выбрать машинку с лучшим разгоном или другую с большей максимальной скоростью. И там, и там будут свои преимущества и недостатки.

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

У джунов, в большинстве случаев, есть главный недостаток, с которым очень и ОЧЕНЬ сложно бороться - это гиперактивность. С одной стороны, энергия это хорошо. Человек будет пахать день и ночь, писать, пилить, билдить, ломать, снова пилить, и с таким упорством, которому все фитоняши в спортзале позавидуют. Однако если эту энергию не направлять в нужно русло, рискуешь словить 100500 вариантов имплементации одного функционала, каждый из которых не будет работать. Поэтому сеньоры-помидоры и прочие менторы хороши не только тем, что знают как правильно делать, но и могут терпеливо, раз за разом, поворачивать молодую пушечку в нужное направление.

Однако нанимать джунов все равно нужно. Я, возможно, приеду в Москву и даже прочитаю небольшую лекцию на эту тему на митапе, но если вкратце - вы, возможно, наймете максимально лояльного фирме человека (это только один из плюсов). Лояльнее зеленого джуна, только что получившего корочку бауманки, может быть только Core Dev, который помнит контору еще в гараже.

Но не стоить хаять компании, которые так не делают. Да, писать постики про “ссущих щеночков” это кошмар, и таким людям не стоит жать руку при встрече, но часто контора не может себе позволить джунов. Их дорого и долго обучать (свежий сеньор потратит МИНИМУМ полгода, пока достигнет продуктивности, корелирующей с командой, что про джуна говорить), их дорого перевезти из другой страны (особенно из еврозоны), и их ошибки стоят не дешевле, чем ошибки сеньоров.

Ну и важно помнить, что junior - это не job title, это склад ума. И одна из главных причин, по которой я начал свой цирк с конями и менторством, чтобы вышибить этот mindset из максимального количества людей, которых я смогу потянуть.
Начинающим же (по-настоящему начинающим) специалистам могу посоветовать только одно - планируйте свое развитие этапами по полгода не более чем на год вперед. Потом поймете почему.

Один из учеников довольно креативно сделал домашнее задание: https://telegra.ph/Rehplikaciya-muskula-10-05

С прокурора орнул.

Как же я люблю 21-ый век.

Дорогие читатели, извините за отсутствие контента.

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

Stay tuned, как говорится! Если у вас есть какие-то пожелания и идеи - вы знаете кому писать.

Теперь, когда я отстрелялся, самое время поговорить об экзаменах, сертификации и всем таком.

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

Большинство экзаменов, особенно состоящих из теории и практики, требуют от человека определенной подготовки, и не только по конкретному продукту. Экзамены Cisco содержат вопросы по маршрутизации и сетям в принципе, в Oracle’овых есть вопросы про SQL, про линуксовые нечего и говорить.
Далее, чем выше уровень экзамена (от начального до профессионального), тем сложнее экзамен и тем больше навыков требуется для его прохождения.
Помимо этого, сертификаты служат своего рода минимально планкой для зарплаты. Человек, защитивший CCNP, мог расчитывать на определенный зарплатный минимум в США, ниже которого ему не могли предложить.

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

Конечно, сертификат должен быть ограниченным по времени. Мир не стоит на месте, выпускаются новые версии с этими вашими killer feature и breaking changes.
Oracle 11-ой версии кардинально отличается от 10-ой, а 12-ая версия так вообще не имеет практически ничего общего с 11-ой.

Но вернемся к экзамену, который я недавно сдал - AWS Certified Developer Associate (June 2018 Edition).
Год назад я сдавал архитекторский экзамен (AWS CSA Associate) и вывел простую формулу: если вам попадается вопрос в стиле “Что из изложенного неправда по отношению к сервису Х?” и ниже идут варианты ответов “Сервис Х не умеет У” и ниже “Ничего из этого неправда”, то вариант “Ничего из этого неправда” скорее всего будет правильным. Почему? Потому, что Амазон как бы тонко намекает на свою крутость, и что они могут почти все.

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

И, наконец, самая мякотка - Амазон будет совать в свои экзамены не сколько те темы, которые нужны вашей специализации, но столько те, которые у них идут одним разрядом mission critical service. Среди таких: DynamoDB, SQS, API Gateway, SNS и наша всеми любимая Lambda.
Подобно Apple, убравшей разъем jack и седьмых айфонов и младше, чтобы посадить всех на беспроводные наушники, Амазон активно пихает эти сервисы, и на экзаменах будет проверять ваше знание именно по ним, не давая пространства для расширения кругозора и мышления в сторону других сервисов.

Я не могу раскрывать вопросы, которые мне попались, но среди них был один, где была гипотетическая ситуация: у вас есть база данных, которая со временем стала тормозить, и вопрос заключается в том, что делать. Среди вариантов ответа - выставить ElastiCache перед RDS или же переписать и перетащить данные на DynamoDB. Мозгом вы конечно понимаете, что поднять кластер ElastiCache наименее болезненная задача и для вас, и для ваших коллег, но вы, я уверен, уже поняли какой ответ правильный. 😉

В итоге, можно сказать, что в случае с Амазоном нас ждет то же, что с Apple - он будет двигать тренды, вовлекая в свой vendor lock всех своих пользователей (а значит другие провайдеры будут делать то же самое) и отпугивать тех бедных ребятишек, которые все еще сидят on-prem и не хотят лезть в облако, потому что дорого и много переписывать (а если вы хотите ПРАВИЛЬНО мигрировать в облако, то придется МНОГО переписывать).

Не знаю хорошо это или плохо. Просто это данность.

P.S. А экзамен я, конечно же, сдал и ожидаю сертификат на этой неделе.

Нарвался тут недавно на канал “Архитектор_говорит” (@architect_says).
О том, как я туда попал (и благодаря кому попал, и что я там прочитал) я расскажу позже. (Спойлер: там хаят мои любимые микросервисы, и я просто не могу молчать.)

С автором канала я лично не знаком, наши пути вряд ли когда-то пересекутся, и это хорошо - мы думаем и смотрим на вещи совсем по-разному.
И если я готов игнорировать его мнение про “Монолит против Микросервисов”, последнее (на момент написания этого поста) сообщение я игнорировать не могу.

Итак, прямая цитата:
“У меня между делом спросили, почему это канал так называется.
Ответ очень простой - как понять, что архитектор занят работой? У него губы шевелятся.
Рот закрыл - рабочее место убрал.”

Здесь могла бы быть ваша шутка про работу ртом, но ее не будет.

Я с точностью могу сказать одно: я не пройду собеседование у господина @meowthsli, а он не пройдет его у меня (даже если мы будем разговаривать по темам из TOGAF, игнорируя конкретику вроде построения вычислительных систем на базе Java + Oracle или AWS).

Не нужно читать множественные job desctiption’ы и описания вакансий ИТ архитекторов, Solutions архитекторов, системных архитекторов, да каких угодно, чтобы знать, что архитектор, в первую очередь, проектировщик, исследователь, и в некоторых случаях, прораб и исполнитель.
Почему вы никогда не видели и не увидите junior архитекторов? Потому что их не существует. Эта должность, титул или роль зарабатывается очень много времени, за которое нужно проделать огромный пласт работы, побывав на обеих сторонах баррикад (Ops и Dev разумеется), обладая экспертизой не в одной, но нескольких областях.

Когда вы назначаетесь на проект архитектором, вы должны не только спроектировать, спрототипировать и собрать “скелет” будущего продукта, но и донести до всех (ВСЕХ) stakeholder’ов, исполнителей (разрабов и админов), до бизнеса, если понадобится, почему надо именно так и никак иначе. И это - первая и единственная часть, которая реализуется ртом (а еще с помощью Visio/Lucidchart и несколькими написанными заранее версиями будущего продукта). После этого вы будете продолжать общаться с людьми, но уже по конкретным вопросам и часто меняя структуру продукта по разным причинам.

Считать после этого, что архитектор работает ртом, а его главные job tools это переговорка, листки с бумажками, ментальные шаблоны и прочая менеджерская шушера как минимум странно, как максимум - абсурд.

Есть должности, в которых софт скиллз важнее хард скиллз, но архитекторская не среди них.

Впрочем, мы с Говорящим Архитектором совсем из разных эпох, миров и прочего, и этот пост не несет в себе цели кого-то оскорбить. Автор “братского” канала приглашается к дискуссии, если конечно мой пост до него долетит.

Как говорится: “Мама, я в телевизоре!”

https://twitter.com/FelixTheBest/status/1055024780594823169

Знаете, почему я люблю Телегу? Потому что тут нет built-in комментариев.
Нравится - читаешь, не нравится - не читаешь.

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

Спасибо за бесплатную рекламу, котятки, и отдельное спасибо читателю, который со мной этим поделился.

А посмотрите выступление моего коллеги по основам мониторинга!
Будет полезно тем, кто специализируется на стеке Микрософта: https://livestream.com/gaelcolas/PSConfAsia/videos/182076933

Коллеги по цеху попросили пояснить за Serverless.

Поясняю: https://telegra.ph/Serverless-10-26

Ну что, доступно пояснил, или остались вопросы?

Если вам что-то не понравилось или непонятно - смело пишите, отвечу на все вопросы по возможности.

Вообще, откуда я прознал про архитектора-говоруна? Благодаря Диме, который выложил у себя пост говоруна с ссылкой на Хабр. Дима держит классный канал, в котором пишет и репостит то, что в современном мире все так любят - кубер, гошечку, прометей, митапчики и много много всего.

С Димой я знаком лично, зная насколько он мозговит, хочу видеть в его канале не только репостики, но и авторский контент. Давайте его растормошим.

Дима, я знаю, что тебе есть что рассказать.

https://t.me/count0_digest

Нет худа без добра.

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

Прямая цитата: “Путь таких aws-архитекторов заканчивается, когда в конце энного года наконец-то задается простой вопрос: почему мы тратим на aws 10m в год?”

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

Если вы уехали, уезжаете или планируете уехать в облако, делаете это не своими силами, а силами посторонних людей или организаций, то вот краткий чек-лист, при котором человека/организацию надо гнать в шею:
- Если TCO (total cost of ownership) после переезда стал неадекватно выше, чем до (к этому еще добавьте расходы на обслуживание инфраструктуры).
- Если приложение или приложения стали валиться чаще после переезда (без существенных изменений в самих приложениях)

Про расходы все просто. Одно дело, когда продукт растет, и с объемами и новыми требованиями появляются новые расходы. Другое - когда нанятый человечек тупо назаказал огромных тачек, даже не приложив усилий к изменению структуры ИС.
Про падающие приложения надо сказать отдельно. Ни один облачный провайдер не будет гарантировать вам 100% uptime. Какие бы сервисы вы там не подняли, Амазон оставляет за собой право взять и перезагрузить вашу тачку. Если внедренец-мигратор не построил вашу структуру хотя бы вокруг ELB + AutoScaling, то его компетенции вызывают очень много вопросов.

Другое дело, что такие косяки всплывают, когда контракт закрыт, дела переданы, претензий не предъявить. Именно поэтому я всегда рекомендую переезжать своими силами.

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

P.S. Буду рад, если со мной свяжется представитель или сотрудник той конторы, которая стала внезапно тратить на AWS 10 миллионов в год (не важно RUR или USD). Если только цифры взяты не от балды, разумеется. 😉