Завтра в 18:00 намечается Kyiv DevOps Community Meetup, спикеры — все очень классные участники сообщества:
https://www.facebook.com/events/414266543706233 <-- тут можно нажать “Пойду”
https://www.youtube.com/watch?v=IghhSgShKlc <-- тут будет трансляция и можно поставить напоминалку

Доклады:
Migration logs system from ELK to Clickhouse
AWS macOS EC2 Instances
Monitoring Platform 101

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

Хаха, амазон заспойлерил что у лямбд будут URL искаропки. Доки уже удалили, но в кеше всё ещё есть. Ждёмс.

https://webcache.googleusercontent.com/search?q=cache:Qr4xUaiHjAsJ:https://docs.aws.amazon.com/lambda/latest/dg/invocation-urls.html+&cd=1&hl=en&ct=clnk&gl=us

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

https://news.1rj.ru/str/uasymposium/19

А тем временем Амазон зарелизила поддержку terraform в AWS Proton (я даже не знал что у них такое было)

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

https://aws.amazon.com/blogs/aws/new-aws-proton-supports-terraform-and-git-repositories-to-manage-templates/

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

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

https://www.jetbrains.com/fleet/

А вообще, если круто сделают (а JetBrains вообще крутые), то представляю как будет обидно всем кто купил новенькие мощные макбуки.

P.S. записался на бету и жду

хорошая статья о том как поэксперементировать с OPA gatekeeper (политики для кубера) при помощи kind (kubernetes in docker) https://medium.com/@LachlanEvenson/verifying-container-signatures-on-kubernetes-with-gatekeeper-19a4519c3016

https://aws.amazon.com/blogs/aws/new-amazon-ec2-m6a-instances-powered-by-3rd-gen-amd-epyc-processors/

уууу, новые инстансы амазона обещают быть на 35% более производительными.

неделя AWS. Тут ещё кафка серверлесс. Я сначала обрадовался, а потом цены посмотрел и загрустил. https://aws.amazon.com/about-aws/whats-new/2021/11/amazon-msk-serverless-public-preview/

ну штож, а вот и новый автоскейлер. https://karpenter.sh/

Выглядит как автоскелер с человеческим лицом завязанный на ресурсы куба.
И судя по докам — умеет в спот инстансы, что вообще даже не верится.

Внезапно - релиз plumber 1.0, моей любимой утилиты для работы с Кафкой и другими очередями✌️✌️

https://github.com/batchcorp/plumber

А мы тут делаем список кресел для сидения что б спина не болела. Пишите свои в комментарии или сразу делайте PR https://github.com/ukrops/newbie/blob/master/README.md

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

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

https://aws.amazon.com/about-aws/whats-new/2022/01/instance-tags-amazon-ec2-instance-metadata-service/

Меня вообще поражает как часто люди и компании героически преодолевают проблемы которые сами себе и создают. Roblox - сервис которым пользуется 50 миллионнов человек упал на три дня.

Они выпустили неплохой постмортем, в котором рассказали о причинах и последствиях. https://blog.roblox.com/2022/01/roblox-return-to-service-10-28-10-31-2021/

Правда судя по выводам они не поняли, что проблема не техническая, а архитектурная.

Что случилось?

Вкратце — у них упал консул после обновления на проде. Из-за чего упал сервисдискавери, номад не смог поднимать новые поды и vault отказался работать тоже.

Почему это архитектурная проблема?

Потому что если у вас всё завязано на один сервис, то когда он упадёт, то всё перестанет работать.
Если вы используете консул и как service discovery, и как БД для номада, и как БД для vault и как просто KV store, то ну у вас всё упадёт если упадёт consul.

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

* vault начал больше писать-читать
* номад начал больше писать-читать
* сервисы начали больше писать-читать


Я иногда слышал доводы от сторонников всё писать в одно место, мол якобы так проще инфраструктура. Но простая инфраструктура ≠ меньше компонент. Было бы у них просто по одному кластеру на каждую задачу — проблема бы не затронула всю компанию. Хотя да, это было бы аж на +20 строчек кода тераформа больше и невероятно сильно усложнило бы инфраструктуру.

Вторая проблема тоже 100500 лет как известна — кешируйте сервис дискавери.

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

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


И проблема даже не в том, что кто-то не подумал заранее. Мне не нравится что в выводах никто в Roblox не подумал — а может у нас плохая архитектура? Может надо что-то изменить на более высоком уровне?

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

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

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

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

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

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

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

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

а ребята из HUG Kyiv делают Q&A с хашимото (основатель хашикорпа) прямо сейчас. Присоеденяйтесь https://www.youtube.com/watch?v=GCvhy4I2bzU

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

Дебаггер позволяет не только дебажить программы, duh, но вообще отличный инструмент для знакомства с кодом. Типа просто запускаем код и растыкиваем брекпоинты хоть в самой первой функции и дальше смотрим что происходит. И даже если не знаешь языка на котором код написан — всё равно можно понять что происходит и почему.

Ещё классная штука — условия для брекпоинтов. В IDEA можно как поставить условие, мол останови если переменная в этом брекпоинте будет иметь такое-то значение. Но ещё удобнее условие - останови если какой-то из брекпоинтов был пройден.

Например, у меня есть два теста и я хочу пропускать первый и смотреть только второй. Для этого я ставлю на втором тесте брекпоинт, щелкаю на нём правой клавишей мыши и убираю “suspend” - то есть он будет проходить, но не будет останавливаться.

Теперь я могу поставить второй брекпоинт в коде, щелкнуть на нем правой клавишей, перейти в “more” и выбрать предыдущий брекпоинт в меню “disable untill hitting the folowing…”

В итоге первый тест пройдёт без остановок, а IDEA запустит окно дебаггера только на втором тесте.

В дебагере ещё много чего полезного есть. Если интересно, могу ещё какие-то полезняшки написать.