I hate overtime

пятнично-новогодний мем

Интересные новости подъехали: Percona Monitoring and Management(продукт для мониторинга БД) переехал с Prometheus-based хранилища на VictoriaMetrics-based. При этом основной притензией к прому, как я понял из блога, была сложность настройки сети из-за pull-модели получения метрик. Целевым решением стал переезд на VM и использование по-дефолту push-модели Я не берусь комментировать решения коллег из percona, но для меня это выглядит, как минимум, неоднозначно. Уверен, что парни рассмотрели альтернативы и приняли взвешенное решение, но в статье это как-то не отразилось(

Поймал себя на том, что достаточно часто у сервисов со сложной логикой физически отделяю api от этой самой логики, связывая их мостиком из очередей. Занятно, что такой паттерн замечал у многих коллег, но мало кто смог ответить на вопрос о причинах такого разделения. Кароч, котаны, цимес такой: очень часто к api и бекенду у клиентов предъявляются разные ожидания. Апишка должна быть шустрой и всегда доступной(тот самый рыжий AP из CAP-теоремы), но при этом может отдать не особо актуальную инфу. Для бекенда, особенно работающего с денюжкой, часто важна строгая консистентность, но при этом никто не расстроится если он время от времени ненадолго приляжет(CP из CAP). У нас такие не особо нагруженные бекенды могли в кубернетисе даже без резервирования крутиться)) В самом деле, клиент не очень расстроится, если его заявка будет обрабатываться на 5 мин дольше, в случае подключения интернета у провайдера, или заказа нового иксбокса в магазине, но при этом будет недоумевать, если ему в лицо швырнуть 500кой или крутить спинером пока его заявка проходит все ваши CRM и ERP. Вот такой вот интересный патерн. Го в комменты, делитесь своими мыслями, рассказывайте юзаете такое или нет

#books Прочитал книжку А. Левенчука "Системноинженерное мышление", очень рекомендую! Не смотря на то, что я последние несколько лет очень интересовался вопросом описания и понимания больших и сложных систем, и изучил немало материала на эту тему, из книги все равно почерпнул для себя достаточно много инсайтов. Кстати, там достаточно много ссылок и на другую годную литературу. Безусловно есть и минусы. У книги очень растянутое введение, т.о. если решите читать, то первые страниц 100(примерно треть книги) рекомендую просто пролистать

Давно у нас не было пятничных мемов

Приходите 2 декабря на вебинар по парсерным комбинаторам на TypeScript, который я буду вести в качестве гостя коммьюнити Math.random(): https://mathrandom.com/webinar0212 Материал рассчитан на начинающую аудиторию, поэтому я начну с азов: быстренько пройдусь по крохотной части теории компиляции, разберу понятие функционального парсера и парсерных комбинаторов, и покажу, как мне изящно удалось решить задачу парсинга строки поискового запроса с булевыми операторами в ней в ~200 строк кода (а на самом деле даже меньше).

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

На Полезняшки от "Разбора Полетов" ссылка битая, правильно @razborfeed Заодно докину еще своих каналов, не упомянутых выше: @SelectelNews и @unidataline в представлении не нуждаются)) @srv_admin --  канал линукс-админа. Так же у чувака есть блог с кучей полезных туториалов @ITMeeting -- аггрегатор событий в IT мире @emacsway_log -- DDD мишка @randomstuffilike @scala_channel_ru @scalabin и @daily_ponv -- ФП @count0_digest --  подезности про DevOps и SRE @AwesomeKafka_ru -- канал Виктора Гамова про кафку @sergeysova и @kamyshev_code-- фронтенд @consensus_io -- распределенные хранилища и алгоритмы конценсуса @dddevotion -- еще DDD @microservices_arch @it_arch-- архитектура, микросервисы и вот это вот все

Не оплаченный пост🖖 Решил сделать подборку своих каналов в телеграме, здесь штук 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

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

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

#distributed #lectures #edu Странный состав лекций, возможно есть предварительный осенний курс. Но это MIT. https://www.youtube.com/playlist?list=PLrw6a1wE39_tb2fErI4-WkMbsvGQk9_UB

#distributed #lectures #edu За авторством Мартина Клеппманна. https://www.youtube.com/playlist?list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB

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

#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кк$

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

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

Одна из самых важных теорем в распределенных системах - C̶A̶P̶ FLP теорема. Она строго доказывает, что невозможно достичь консенсуса, если: 🔸 Система асинхронна (что справедливо для реальных сетей) 🔸 Хоть один из узлов может отказать 🔸 Алгоритм детерминирован И тут возникает вопрос - а как же алгоритмы консенсуса Paxos/Raft? Paxos/Raft работают строго в рамках этой теоремы. У обоих алгоритмов существуют сценарии, при которых они не будут совершать прогресс, т.е. выбор одного значения на узлах никогда не завершится. Пофиксить это можно убрав какое-то условие из FLP, например детерминизм. Raft убирает детерменизм c помощью рандомных таймеров при выборе лидера, чтобы избегать таких сценариев. Если вы вдруг придумали алгоритм консенсуса - найдите такое исполнение, при котором система не сможет совершать прогресс. Алгоритм консенсуса не может нарушать FLP теорему! В общем, теорема не означает, что консенсус недостежим. Она лишь означает, что консенсус не всегда достежим/недостежим за детерминированное время. Это важно понимать. #flp #theory