#management #sre
Подробный рассказ о процессе инцедент-менеджмента в Heroku. Артикль интересен тем, что у них свой процесс, достаточно сильно отличающийся от ITIL-based и от описанного в SRE book

#msa #arch
Очень хорошая статья про технические питфолы микросервисной архитектуры. Автор разбирает 4 челенджа: интеграцию и транзакционность, авторизацию, кроссервисные бизнес-процессы и версионирование + приводит кучу интересных ссылок на каждую тему.
Рекомендую просмотреть и походить по ссылкам (особенно тем кто уже разросся до масштабов нетфликса, вкрутил девопс и продуктовую разработку, лол)

#security
Кстати, тут коллеги очень интересную штуку откопали. Это протокол авторизации a-la OpenID, но позволяющий проверять claim на валидность без отправки самого клейма и остальных клеймов. Т.е. если один черножелтый ресурс просит вас подтвердить, что вам есть 18, то этот протокол позволит вам это сделать без отправки даты рождения и остальных данных

Оператор в #kubernetes для управления кластерами БД

https://habr.com/ru/post/523378/

https://youtu.be/z2aARjKDg4w

#k8s #clickhouse #kubernetesoperator #database #db #altinity

#sre #metrics
Котаны, откопал тут древний видос от Coda Hale про мониторинг. Если не смотрели, то очень рекомендую. Меня вот очень зацепила фраза со слайда: "If it could affect your code's business value, add a metric"

#sre #logging
Подробная(возможно даже чересчур) инструкция по настройке логгинг-стека Vector+Clickhouse

Хех, история в стиле помоги Даше найти хешсет)) Понадобился мне тут как-то хешсет в C# проекте, да не простой хешсет, а конкурентный! Ну, думаю, нам же выдали набор lockfree коллекций System.Collection.Concurrent, но, внезапно, нужного среди всяких ConcurrentQueue и ConcurrentDictionary не находится. Уже в предвкушении взял попкорна и колы и пошел на гитхаб.
И вуаля! Предлагают взять ConcurrentDictionary и просто не юзать второй элемент)) Современные проблемы требуют современных решений, хех))
З.Ы. после долгих обсуждений все-таки сделали пропозал

📄 Write code that is easy to delete, not easy to extend is a guide (an essay?) on when it's good to copy-paste a code and when it's not, when it's good to split a code by pieces and when it's better to keep all things together. These are hard questions but we should think and talk about it.

Одна из самых важных теорем в распределенных системах - C̶A̶P̶ FLP теорема.

Она строго доказывает, что невозможно достичь консенсуса, если:
🔸 Система асинхронна (что справедливо для реальных сетей)
🔸 Хоть один из узлов может отказать
🔸 Алгоритм детерминирован

И тут возникает вопрос - а как же алгоритмы консенсуса Paxos/Raft?

Paxos/Raft работают строго в рамках этой теоремы. У обоих алгоритмов существуют сценарии, при которых они не будут совершать прогресс, т.е. выбор одного значения на узлах никогда не завершится. Пофиксить это можно убрав какое-то условие из FLP, например детерминизм. Raft убирает детерменизм c помощью рандомных таймеров при выборе лидера, чтобы избегать таких сценариев.

Если вы вдруг придумали алгоритм консенсуса - найдите такое исполнение, при котором система не сможет совершать прогресс. Алгоритм консенсуса не может нарушать FLP теорему!

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

#flp #theory

Маркетинг MongoDb бессмысленный и беспощадный

Ну что ж, паны айтачи, видимо сегодня день мемов

#arch #business_model
Котаны, разбирая тут свои "read later" завалы наткнулся на замечательную статью от Nick Tune(создателя C4) про связь IT и Business Models (вообще в статье про Software Architecture, но очень легко обобщается на все IT в целом)
ТлДр такой: часто когда нас просят сделать фичу она кажется глупой, бессмысленной или черезвычайно дорогой("ой, вот еще щас всю архитектуру менять😡"). Ник предлагает рассмотреть продукт со всеми его фичами с точки зрения бизнеса, используя удобный Business Model Canvas. Таким образом, психологически становится сильно проще коммуницировать с аналитиками\продуктами в поиске win-win решений.
У нас, кстати, продуктологи в какой-то момент начали указывать Customers Segments и Revenue прямо в спецификации. Согласитесь, сильно приятнее делать не просто фичу FO-666, а FO-666 для 20кк пользователей с потенциальным доходом 10кк$

Ребята из propensive.com запустили бесплатный курс по Scala 3. Если нет планов на выходные, то хватайте чаек с печенюгами и ну-ка быстро осваивать новую скалку!

#distributed #lectures #edu

За авторством Мартина Клеппманна.

https://www.youtube.com/playlist?list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB

#distributed #lectures #edu

Странный состав лекций, возможно есть предварительный осенний курс. Но это MIT.

https://www.youtube.com/playlist?list=PLrw6a1wE39_tb2fErI4-WkMbsvGQk9_UB

Котаны, последнее время на канале нет нового контента. Это потому, что я сменил галеру и пока что очень много времени трачу на работу.
Кстати, на новом месте увидел достаточно интересный подход к взаимодействию системных архов и разработчиков: архитектор детально прописывает изменения в API и схеме(ах) БД перед разработкой фич. В итоге к dev'ам прилетают достаточно подробные, но жирные спеки. На прошлых местах работы мы делали более высокоуровневое up-front проектирование, но больше времени и внимания уделяли контролю за реализацией и метриками.
К сожалению, я еще не успел понять работает ли такой подход или парни просто не читают эти спеки, так что ждите новых заметок с фронтов)) А пока опросик

Ну чтож, мне кажется, что опрос удался! Подведем итоги, тем более что результаты крайне интересные: очень радует, что большинство все таки живет в согласии с собой и довольно текущей ситуацией)) При этом, надо сказать, что противников Big Up-Front Design подхода все-таки больше чем союзников. Хотя и сторонников детальных спецификаций все же не мало.

Закончу, пожалуй, своим ИМХО на этот счет: дело в том, что, как не крути, сейчас рыночек решает в сторону более динамичных компаний, вследствие чего, пышным цветом цветут agile, lean и пр. методологии дающие бизнесу больше пространства для маневра. К сожалению, за бОльшую гибкость на стороне продукта, IT приходится платить бОльшими рисками и неопределенностью, что, в свою очередь, приводит к более хаотичной(т.н. эмержентной) архитектуре. Просто представьте себе человека, который 2 мес детально проектировал систему для продажи обуви online, а под конец к нему пришли и сказали, что рыночек поменялся, capability-окно закрылось и теперь нужна система по управлению франшизой шаурмяшных. Что-то мне подсказывает, что взрыв будет похлеще чем на ЧАЭС😁 Вот что бы не оказаться на месте этого бедолаги, умные дядьки типа Neal Ford, Simon Brown, а теперь еще и целого Open Group придумали целый набор метод, позволяющих архитекуртить архитектуры в условиях полнейшего agile головного мозга. К сожалению(или к счастью), все эти практики сконцентрированы вокруг принятия а не борьбы с этой самой эмержентностью и предлагают сосредоточиться на господстве над хаосом, а не попытках его обуздать. Т.о. получается что сторонникам BUFD придется потихоньку адаптироваться т.к. против рыночка не попрешь

Не оплаченный пост🖖

Решил сделать подборку своих каналов в телеграме, здесь штук 10 нет т.к. там не часто пишут посты или же с мемами каналы, но думаю с мемами вы и так найдёте.

Спасибо авторам и людям, которые их ведут и обновляют❤️

@tech_b0lt_Genona
@alexmakus
@catops
@devopslibrary
@flant_ru
@linuxgram
@opensource_findings
@hacker_news_feed
@oleg_log
@oleg_fov
@generictalks
@overtimehate
@nosingularity
@cybershit
@bykvaadm
@sqaunderhood
@evilmartians
@sudo_rmrf
@bortlog
@qaload
@lovely_it_hell
@badoo_tech
@buhtig
@opennet_ru
@razborfeeda
@automation_remarks
@experimentalchill
@itgram_channel
@manandthemachine
@good_bad_reviewer
@sec_devops
@tmfeed
@your_tech