Site Reliability Engineering (Рубрика #SRE)

Fb напомнил мне, что три года назад я постил свои впечатления после прочтения книги "Site Reliability Engineering. Надежность и безотказность как в Google".
Тогда книга определенно понравилась, но есть нюанс ... Нюанс заключается в том, что название SRE в головах людей получило коннотацию Devops, что в принципе неплохо, но ... у кого из знакомых разработчиков я не справшивал читали ли они эту книгу, то получал ответ в стиле "Нет, это вроде что-то для devops'ов"🙂 А на самом деле книга определенно хороша и ряд глав стоит прочесть разработчикам в первую очередь.

Структура книги довольна проста и состоит из 5 частей:
1) Введение
2) Принципы
3) Практики
4) Управление
5) Выводы

В введении кратко описывается содержание книги, а вот уже в принципах начинается интересное и рассматриваются вопросы, касающиеся:
- менеджмента рисков (глава 3)
- определения качества обслуживание сервиса aka SLO, SLA, SLI (глава 4)
- избавления от рутины (глава 5)
- мониторинга распределенных систем (глава 6)
- технологий выпуска ПО (глава 😎 - эту главу рекомендую разработчикам
- простоты (глава 9) - эту главу рекомендую разработчикам

В части, касающейся практик, приводится порядка 20 глав, среди которых особо важны для разработчиков главы касающиеся:
- тестирования надежности систем (глава 17)
- балансировки нагрузки на уровне фронтенда (глава 19)
- балансировки нагрузки в датацентрах (глава 20)
- способах борьбы с перегрузками (глава 21)
- способах борьбы с каскадными сбоями (глава 22)
- разрешениях конфликтов в распределенных системах и достижения консенсуса (глава 23)
- распределенный cron (глава 24)
- конвейеры обработки данных (глава 25)
- сохранность данных (глава 26)

В части про управление расказано о некоторых вопросах менеджмента команд SRE. А в последней части, называющейся "Выводы" проводятся параллели между разработкой ПО в Google и разработкой mission critical систем в авиастроении, кораблестроении, атомной энергетике и т.д.

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

#SRE #Software #SystemDesign #Architecture #SoftwareArchitecture

Defense Industrial Base Guide: Detecting Agile BS - интересный 5-страничный гайд от министерства обороны США, посвященный теме распознавания Agile Bullshit, когда гибкие подходы только декларируются, но не имеют отношения к реальности:) Он был написан в 2018 году, но до сих пор актуален.

Вот, например, как трансформированы 4 основные мысли Agile:
1) Individuals and interactions over processes and tools -> “Competence trumps process”
2) Working software over comprehensive documentation -> “Minimize time from program launch to deployment of simplest useful functionality”
3) Customer collaboration over contract negotiation -> “Adopt a DevSecOps culture for software systems”
4) Responding to change over following a plan -> “Software programs should start small, be iterative, and build on success ‒ or be terminated quickly”

Дальше в документе указываются некоторые паттерны, которые сразу позволяют понять, что в твоем проекте не все хорошо. Например,
- Nobody on the software development team is talking with and observing the users of the software in action; we mean the actual users of the actual code.
- Continuous feedback from users to the development team (bug reports, users assessments) is not available.
- Meeting requirements is treated as more important than getting something useful into the field as quickly as possible.
- Stakeholders are acting more-or-less autonomously (e.g. ‘it’s not my job.’)
- End users of the software are missing-in-action throughout development
- DevSecOps culture is lacking if manual processes are tolerated when such processes can and should be automated

После этого авторы документа перечисляют современный инструментарий для организации нормальной разработки.
А потом идут вопросы, которые стоит задать различным участникам проекта, чтобы поставить диагноз точнее:)
В общем и целом, интересный документ. Сомневаюсь, что подобный документ есть и используется в министерствах обороны других стран:)

P.S. Сам документ можно изучить здесь - https://bit.ly/AgileBSbyDIB

#Agile #Processes #Software #SoftwareDevelopment

Раньше я успевал читать еще и научно-популярные книги по физике, например, такие как книга Джима Аль-Халили "Парадокс. Девять великих загадок физики", выпущенная в серии New Science. В книге отлично подаются парадоксальные вопросы физики. Но начинает автор с простым математических историй, относящихся к теории вероятности, а именно с Парадокса Монти Холла и парадокса дней рождений. Первый интересен мне тем, что я его услышал первый раз лет в десять от своего тренера по шахматам, который мне периодически подкидывал интересные задачки и методички на развитие когнитивных способностей. Насколько я помню, в детстве мне было сложно понять в чем суть этого парадокса даже с объяснениями тренера. В итоге, я разобрался уже в старших классах школы, когда поизучал немного университетские учебники по теорверу:)
Интерсно, что формулировка парадокса Монти Холла простая, а большинство моих знакомых, впервые услышавших его, отвечают на поставленные вопрос неправильно. Приведу для интереса формулировку прямо в посе
"Представьте, что вы стали участником игры, в которой вам нужно выбрать одну из трёх дверей. За одной из дверей находится автомобиль, за двумя другими дверями — козы. Вы выбираете одну из дверей, например, номер 1, после этого ведущий, который знает, где находится автомобиль, а где — козы, открывает одну из оставшихся дверей, например, номер 3, за которой находится коза. После этого он спрашивает вас — не желаете ли вы изменить свой выбор и выбрать дверь номер 2? Увеличатся ли ваши шансы выиграть автомобиль, если вы примете предложение ведущего и измените свой выбор?"
В общем, если вам интересно, то можете почитать про этот парадокс. А я пойдут дальше, т.к. дальше автор переходит к физическим вопросам, которые включачют:
- парадокс Зенона про Ахилесса и черепаху - бесконечно малые ряды
- Демонов Максвелла и Лапласа - первый про второй закон термодинамики, а второй про теорию хаоса
- парадокс близнецов и парадокс дедушки - первый про специальную и общую теорию относительности, а второй про путешествия во времени
- кота Шредингера - про квантовый мир и переход к макромиру
- парадокс Ольберса и парадокс Ферми - первый про то, почему ночью темно, если звезд так много, а второй про то, где же зеленые человечки, если звезд так много и много планет вокруг них.
Напоследок автор высказывает набор вопросов, которые еще предстоит разгадать.

#PopularScience #Physics

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

#Presentations #PublicSpeaking #Pitching

Просто оху...ное выступление John Ousterhout, профессора CS из Стэнфорда. Одного из создателей скриптового языка tcl, про который мало кто помнит, а также алгоритм консенсуса raft, про который знает большинство, изучавших Distributed Systems.
В этом выступлении он рассказывал про философию Software Design.
Мне особенно понравилась часть про правильный mindset и разрушительных tactical tornados:)
https://youtu.be/bmSAYlu0NcY?t=2040

Кстати, сам я называю это чувством прекрасного в разработке программного обеспечения - если его у тебя нет, то ты скатываешься к выполнению задачек и закрытию тикетов, а твоя система обрастает неэффективными и некрасивыми решениями. Именно поэтому стоит прокачивать правильный mindset и тренировать насмотренность, изучая сложные системы и принципы, которым следовали их проектировщики. Для этого стоит сначала почитать книги, чтобы получить некоторую базу, а потом переключаться на white paper реальных систем, которые вас интересуют:)

#SoftwareDevelopment #SoftwareArchitecture #Software #SystemDesign

The Fabric of Reality: The Science of Parallel Universes (Структура реальности. Наука параллельных вселенных) (Рубрика #Physics)

Книга Дэвида Дойча "Структура реальности. Наука параллельных вселенных" является очень интересной и достаточно сложной и философской.
Пару лет назад я прочитал ее с большим интересом.
В этой книге автор выстроил все свои рассуждения на основе четырех китов:
— квантовая физика в мультиверсной интерпретации
— теория вычисления и тезис Чёрча — Тьюринга — Дойча
— эпистемология как некоторая дисциплина, исследующая знание как таковое, причем в интерпретации Карла Поппера (подробнее в книге К. Поппера "Логика научного исследования")
— эволюционная теория Дарвина в интерпретации Докинза (подробнее в книге Докинза "Эгоистичный ген")
Каждый из этих китов является очень интересной и богатой областью знаний, которые интересно изучать сами по себе. Но смешанные вместе они позволяют Дэвиду Дойчу формулировать очень интересную эмерджентную теорию, включающую
— фокус на объяснительной силе теорий
— объяснение квантовых эффектов типа интерференции на основе многомровой интерпретации квантовой механики
— связи физики и теории вычислений в виде тезиса Чёрча — Тьюринга — Дойча, где универсальное компьютерное устройство способно моделировать любой конечный физический процесс; при этом аппарат классической физики, существенным образом использующий понятия непрерывности и континуума, не позволяет моделировать все физические процессы машиной Тьюринга, которая оперирует лишь с вычислимыми объектами
— использовании эпистемологии для обсуждения эволюционного развития нашего вида, сопровождающегося увеличением общего объема знаний и повышения их объяснительной силы

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

#PopularScience #Physics

Три года назад я был на конференции O'Reilly Software Architecture Conference в Берлине.
Там я посетил тренинг по Event Storming, после чего заинтересовался подходом и прочел одноименную книгу Alberto Brandolini, автора самого подхода.

Впечателения от книги положительные, но, как говорится, есть ряд нюансов ...
Сначала про плюсы:
- автор предлагает интересную механику работы группы людей на воркшопе для построения моделей
- модели бывают трех уровней: большая картинка, модель процесса, дизайн системы. Уровни расположены в порядке drill down
- предлагаемая нотация очень проста и понятна, плюс она вводится постепенно и подстраивается фасилитатором под аудиторию
Если говорить про саму книгу, то самое вкусно расположено в первым нескольких главах, где автор рассказывает о проблематике:
- написание ПО сложно не потому, что сложно написать код
- написание ПО сложно тем, что не всегда ясно что именно надо автоматизировать
- у многих есть свое представление о том, как выглядит big picture происходящего в организации, есть свой взгляд на процессы и т.д.
- потом ребята, что пишут код, сталкиваются с этими двусмысленностями уже в процессе написания кода и решают их по мере возможности
- в итоге, получается не то, что все ожидали
Автор делает логичный вывод, что перед тем как что-то разрабатывать, круто бы понять зачем и что именно. А для этого неплохо подходят воркшопы event storming'а.
К минусам книги стоит отнести, что
- она в процессе написания и пока не окончена (и судя по отношению автора никогда и не будет)
- в книге есть дублирования, самоповторы и нестыковки
- книга выглядит как салат оливье:)
В общем и целом, книга про event storming интересна как и сам event storming:) Рекомендую. А для краткого знакомства можно использовать выступление Alberto на Goto конференции в Амстердаме в 2018 году - https://youtu.be/NGXl1D-KwRI

P.S.
Конференция Software Architecture Conference мне понравилась и я еще 3 года назад в двух стататьях рассказал подробнее чем именно
- https://bit.ly/ArchConf2019-1
- https://bit.ly/ArchConf2019-2

#Architecture #SoftwareArchitecture #SoftwareDevelopment #EventStroming #DDD

В тему последней книги хотел добавить, что в России подход Event Storming активно пропагандирует Сергей Баранов.
У него есть несколько выступлений на эту тему
- На Techlead 2020 - https://youtu.be/cG9DVbcPc9M
- На Spb Dot Net - https://youtu.be/n2RFyLi0sgc

И он же проводит тренинги, где обучает проведению Event Storming в онлайне - https://scrumtrek.ru/product/226/obuchenie-provedeniyu-event-storming-v-onlayn/
Я тоже обучался у Сергея на одном из таких тренингов + взял еще несколько ребят из своих команд, которым это умение могло бы быть полезным.

#EventStroming #Architecture #SoftwareArchitecture

Сегодня буду участвовать в книжном клубе { между скобок }, где мы обсудим часть книги "System Design Interview an Insider Guide".
Если есть желание, то присоединяйтесь в 20.00 по Москве - встреча будет в Zoom и можно будет позадавать вопросы участникам

Всем привет 👋 17 июля в 20:00 по мск встречаемся чтобы обсудить главы CHAPTER 2: BACK-OF-THE-ENVELOPE ESTIMATION  (Глава 2. Приблизительные оценки) и CHAPTER 3: A FRAMEWORK FOR SYSTEM DESIGNINTERVIEWS  (Глава 3. Общие принципы прохождения System Design Interview). Будем говорить про нюансы, которые могут отлечить новичка от профи, так же поговорим про умение слышать и понять вопрос.

Помогать в обсуждение нам будут:
📍Александр Поломодов - Руководитель управления разработки цифровых экосистем в Tinkoff. Отвечает за публичные веб-приложения, мобильный банк, автоматизацию каналов привлечения, сервисы управления данными. Когда-то давно писал требования, код, лидил команды разработки. Входит в программный комитет ArchDays.

📍Николай Голов - Head of data engineering at ManyChat, знает все о том как построить OLAP и OLTP систему, в деталях разбирается в построении аналитических систем.

Вчера вечером я участвовал во встрече книжного клуба { между скобок }, на которой мы разбирали 2 главы из книги “System Design Interview” за авторством Alex Xu. А точнее мы разбирали вторую и третью главы, в которых автор рассказывает про приблизительные оценки (back-of-the-envelope estimation) и делится подходом для прохождения интервью по системному дизайну (a framework for system design interviews). Эти главы показались мне достаточно интересными, чтобы сделать их краткий обзор в статье https://bit.ly/4StepsFromSysDesIntrw

#SystemDesign #SoftwareArchitecture #SoftwareDevelopment #Software #Architecture #ExternalReview