Могу сказать, что с Телеграммом, который то работает, то отваливается, работать уж точно неприятно. Так что в какой-то мере РКН своего добился.

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

Всем до связи.

Ну вот, взял небольшой отпуск, а двух человек сразу нет. Ну ничего. ;)

Я возвращаюсь 30-ого, буду сдавать руководству результаты своего исследования DCOS, заодно расскажу вам, как это происходит.

А пока почитайте интересную статейку. Надеюсь, ребята прошьют туда 3 закона Азимова. :))

https://rb.ru/story/robots-that-teach-themselves-kung-fu/

Все, вернулся в строй.
Приятно вернуться в свою зону комфорта с перманентными дождями, велосипедистами и работающим Телеграмом. :))

Сегодня-завтра ждите разбор на тему: «Как защитить свое исследование перед членами команды.»

Прошу прощения за небольшое опоздание. Итак, поехали.

Защита делится по группам людей, перед которыми надо “защищать” свое исследование (рассматривайте это как защиту диплома).
Защищаться в моем случае надо перед следующими группами лиц:
- перед своей (DevOps/Infra/etc) командой
- перед разработчиками
- перед менеджментом

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

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

А вот третья группы - инженеры - это уже сложно. Вопросов задают много, бьют по недостаткам и очень хотят “быстро, круто и просто” (Spoiler alert - так не бывает).
Основные задаваемые вопросы - как, что и почему. Чаще всего “почему”.

Вот пример кейса - набросали решение, прогоняли на тестовом окружении, сразу вопрос: “А вот это оно умеет?”. И не дай Бог, вы ответите “нет” - придется идти обратно и переделывать.
В моем случае чаще всего задаваемый вопрос был “почему”:
- “Почему tfstate в репозитории?”
- “Почему сборка строго локально?”
- “Почему используется локальная роль, а не instance profile?”
- И много других.

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

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

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

Оставайтесь на связи и не делайте х**ни.

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

Но раз уж зашел один раз в круги, так и варишься в этой котле (Я уже устал блокировать предложения по криптоконтенту от Яндекс.Дзен).

У криптовалютного бума есть один интересный момент - доступность для простых смертных (и лютых криптоанархистов-верунов) позволила людям нехило так обогатиться. Пока одни товарищи льют крокодиловые слезы, просматривая страницы “Сколько бы у вас было денег, купи вы биткоин на 5000 рублей в 2009”, другие успешно покупают себе Ламборгини, квартиры в Норвегии или открывают свои криптобиржи.

Не смотря на неплохую капитализацию, Большие Парни (Уоррен Баффет, Ричард Бренсон и прочие Германы Грефы) держатся (пока) в стороне от этого болота. Оставим причины и переключимся на другую интересную мне тему - Фила Киркорова.

Пошлая Молли, Фейс, Фараон, Версус, Дудь, Ольга Бузова, “Мамочка я не зигую”, Катя Клэп, Сарданов, Ургант, Гудков - я уже не сижу в соцсетях, но я насмотрелся на этих звезд Ютуба. Их популярность измеряется не рейтингом на телевидение, но количеством просмотров на Ютубе и лайков в Инстаграме.

И вот тут Филя К на пару с Ургантом и Гудковым рожает атомную бомбу под названием “Цвет настроения синий”, где Бузова - кассирша с нарощенными волосами, а Лепс так вообще бомж. БОМЖ! 24 миллиона просмотров за две недели. Двадцать. Четыре. Миллиона.
Легким взмахом руки, Король Эстрады (и я пишу это с абсолютным уважением и серьезностью), роняет всех этих доморощенных выскочек одним единственным треком, что твой Фейс роняет Запад. У.

К чему я это все? Сейчас, пока в Штатах проходит Консенсус, Богатые Дядьки Мира Сего, сидят себе спокойно с триллионами долларов и молчат. Когда Они решат, что пора входить в биточек, эфир, риппл и прочее, они устроят тут такой Содом и Гоморру, что за пару часов вся эта эгида профессиональных инвесторов из 8А во главе с Бутериным, братьями-близнецами, Томом Ли и прочими станет бомжами, затем миллиардерами, затем опять бомжами, при этом абсолютно не понимая что происходит.

Потому что есть те, кто на удачу купил биток в 2009-ом, а есть Короли. И Короли всегда выигрывают.

Между делом случилось наконец-то то, что мы так долго ждали.

Блаженный сервис Fargate теперь доступен в регионе eu-west-1. А значит вся моя исследовательская деятельность по Terraform, DCOS и прочему может лететь в мусорный бак, потому что пора адаптировать все под “serverless” контейнерную оркестрацию.

Как же я люблю ИТ. ^^

В общем я в очередной раз напоролся на собственные грабли.

Видите ли, в ИТ все меняется быстро. Очень быстро. Иногда даже слишком быстро.

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

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

Я не буду повторять тут свой пост про “правила” жизни, но напомню про один пункт из него:
- Учиться надо быстро. Быстрее чем конкуренты.

Я сразу вас заверю, что вы никогда не достигнете утопии. Какой бы фотографической ни была ваша память, пока вы осваиваете yet another brand new technology, к моменту, когда вы вдоволь наиграетесь с версией 1, команда из 100500 высококлассных специалистов выкатит уже 8-ую версию.

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

Принялся за книжку “Thoughtful machine learning with Python”.

Нашел удивительный абзац: “Software and airplanes share one common thread: they’re both complex and when they fail, they fail catastrophically and publically. Airlines have been able to ensure safe travel and decrease the probability of airline disasters by over 96%. Unfortunately we cannot say the same about software, which grows ever more complex. Cata‐ strophic bugs strike with regularity, wasting billions of dollars.
Why is it that airlines have become so safe and software so buggy?”

LinkedIn, ты сейчас серьезно?

Открыл для себя недавно две элементарные, но неожиданные истины:

1) Микросервисная архитектура, которую все сейчас так любят, это всего-лишь ребрендированный unix-way.

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

Ух, чувствую завтра на tgstat увижу прикольный стояк в графике просмотров.

Спасибо @theaftertimes и ребятам, которые меня поддерживают, за сей сюрприз. Правда, очень и очень приятно.

Завтра расскажу, что я имел в виду своим последним постом. Не про unix-way (про это дядьки умнее меня уже много где написали), но про пассаж в адрес DevOps’ов.

Чай не Киркоров, так нещадно выпендриваться на коллег по цеху.

Кстати, придумал тут прикольный (на мой взгляд) вопрос для собеседования по знаниям Докера и Амазона.

У вас есть ЕС2 инстанс с IAM ролью с S3FullAccess. На инстансе запущен Docker контейнер, внутри которого нет API ключа и секрета. Из контейнера вы производите API вызов в сторону S3. Пройдет ли вызов? Почему?

Так вот, касательно “плохих” инженеров.

Проблем тут много (очень много), но я пройдусь по основным.

Проблема первая - наколеночно-костыльный велосипедизм.

Когда открываешь всякого рода чаты, каналы и прочие бложики с вложиками, часто нарываешься на прекрасное творчество типа “как сделать Х в У, чтобы получилось Й”. Один раз нарвался на пост, где парень создает ресурсы с помощью Terraform и через него генерирует hosts для Ansible, чтобы потом применить на них роли. Куча лайков и репостов и ни одного комментария ни про provisioner, ни про динамические инвентари в Ansible.
Сделал ли парень что-то не так? Да нет, идея крутая. Правда ее реализовали много раз, по-другому и удобнее.
Почему парень так сделал? Потому что ресурсов необходимых не было. Или знаний. Или тогда не было провиженеров и динамическими инвентарями. Что гадать-то теперь.
Проблема не в продюсере контента, а в его потребителях. Неопытные ребята подхватывают костыльную идею и реализуют ее в своих проектах в бесконечной велосипедной петле. Когда это делается по незнанию, это не страшно. Хуже когда это делается предумышленно, из чего вырастает другая проблема.

Проблема вторая - job security.

Сидит единственный инженер в конторе/проекте. Плохой такой инженер, ленивый и вредный. Хочет контора его уволить, но не может. Инженер создал такую инфраструктуру, которую только он и понимает. Я встречался с такими случаями и всем, кто так делает, гарантирую - контора от вас избавится, как только сможет.
Развитие технологий и платформ привело к тому, что определенная рабочая нагрузка с инженеров снижается. Уже не нужно заботиться о серверном или сетевом оборудовании. Облачные сервисы убрали с нас необходимость настраивать резервное копирование, репликацию, мониторинг и прочее (на самом деле это делают, просто уже не вы). Поднять сервер - 2 клика. Базу данных - 2 клика. Поднять общую файлопомойку - два клика. Срелизить приложение - 2 клика (или один pull request). Развернуть приложение - 2 клика (или вообще без кликов).
А потом у нас появляется Serverless programming и Mike Gualtieri пишет, что не хочет Ops (https://go.forrester.com/blogs/11-02-07-i_dont_want_devops_i_want_noops/). Инженеры нервничают, думая что бизнес от них вот вот избавится, чтобы порезать расходы (и к сожалению, бизнес так часто делает), и собирают нечто, что понимают только они.
Абсолютно игнорируется потребность ходить в отпуск и выключать рабочий телефон. Человек, радея за свою условную зону комфорта, оборачивает себя в кокон вечного стресса, потому что понимает - е*анет, причем вот-вот. Засыпая в обнимку с телефоном, инженер не может приостановиться и оценить масштаб ущерба, размер технического долга и составить план по восстановлению баланса во вселенной. Приводит это к следующей проблеме (не считая, что карьера человека загублена).

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

Минутка шмоточничества.

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

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

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

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

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

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

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

Когда вы окружаете себя недвижимым и в то же время хрупким монолитом, вы тратите свое драгоценное время на удержание этого колосса на глиняных ногах. В результате стек технологий сокращается до количества пальцев на одной руке - осваивать новое попросту нет времени.
Ребята в западных конторах давно это поняли и инициировали движение всеобщей автоматизации (и к счастью русские ребята тоже это поняли и теперь двигают прогресс в СНГ), где инженер тратит 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 проекта.

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