Публичное интервью по troubleshooting для SRE-инженеров на Devoops

Сегодня у меня целых два выступления на разных конференциях. Вечером будет публичное интервью по troubleshooting на Devoops, а днем я расскажу про пути развития senior аналитиков на Flow. Изначально я не планировал такой нагрузки, но выступление на Flow пришлось тоже подвинуть в онлайн:)
Если же возвращаться к интервью на Devoops, то оно посвящено тому как выглядит одно из интервью для SRE инженеров. А выглядит оно как работа в рамках инцидента, где сценарий приблизительно таков:
1. По легенде кандидат и интервьюер работают совместно в SRE-команде. Кандидат исполняет роль Lead, а интервьюер — Junior.
2. Собственно, по той же легенде Lead уезжает на конференцию, а Junior остается дежурить.
3. Дальше происходит инцидент, который они вместе распутывают, так как junior сразу использует "звонок другу" и дальше под руководством лида пытается со всем справиться:)

На публичном интервью я буду выступать в качестве интервьюера, а выступить в качестве собеседуемого согласился Салих Фахрутдинов - Senior SRE в Tinkoff Origination Platform.
Спасибо Салиху и надеюсь, что у нас получится интересно:)

#Engineering #SRE #Career #Interview #Processes #Postmortem #Management

Материалы к докладу на конференции Flow "Как развиваться, если ты уже Senior System Analyst"

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

- Доклад "'Канал. Продукт. Платформа' или эволюция подходов к развитию мобильного банка Тинькофф"
 - Краткий обзор "Team topologies" в трех частях 
 - - Teams as means of Delivery
- - Team Topologies that work for flow
- - Evolving team interactions for innovation and rapid delivery
- Статья "Про performance review в командах разработки"
- Обзор white paper "DevEx: What Actually Drives Productivity"
 - Доклад "Современные подходы к разработке программного обеспечения"
 - Доклад "SOLID'ный тимлид, или основы менеджмента для технарей"
 - Доклад "Как нанимать технических руководителей"
 - Доклад "Как и куда развиваться, если ты уже Senior Software Engineer"
 - Доклад "Варианты роста инженера, если он уже Senior"
 - Доклады про system design interview
 - - в общем про system design в Тинькофф
 - - больше про то, как мы оцениваем прохождение собеседования
 - - как подготовиться к собеседованию
 - -пример на C++ Russia 2022 про проектирование ленты в сервисе видео
- - пример на ArchDays 2022 про проектирование букинга номеров в отелях
 - - пример на C++ Russia 2023 про проектирование умных парковок

#Career #SystemDesign #Software #SoftwareArchitecture #Architecture #Engineering

Как RnD (Research and Development) появляется в крупных ИТ-компаниях

На TeamLead Conf++ 2023 я расскажу доработанный доклад про RnD, который я уже рассказывал на нашем дне открытых дверей в Ереване, но записи которого не велось.

В докладе я попробую ответить на вопросы:
— Зачем крупным ИТ-компаниям заниматься RnD
— В какой момент RnD может появляться и как может выглядеть
— Какие задачи могут стоять перед RnD-направлением
— Как может происходить внедрение инноваций и как сделать этот процесс эффективным

P.S.
Для доклада я возьму другие Bigtech компании, которых нет в статье приведенной выше, а также попробую посмотреть как это происходит в российских компаниях, включая Тинькофф.

#RnD #SoftwareDevelopment #Software #Conference

Practical Magic: The Resilience Potion & Security Chaos Engineering • Kelly Shortridge • GOTO 2023

Интересное выступление от Kelly Shortridge, Senior Principal at Fastly, про Security Chaos Engineering, про которую она написала одноименную книгу.
В самом докладе автор рассказывает про 5 составляющих устойчивость (resilience) системы:

1. Define the system’s critical functions
Зная что относится к критическому функционалу, легко понять что в него не входит, а это позволяет более осознанно действовать как при разработке, так и во время инцидентов. Например, ясно где стоит использовать скучные, но предсказуемые технологии:) Новые и модные технологии стоит использовать там, где это выступает для бизнес-проблем в качестве market differentiator. Здесь же идет речь про важность стандартизации: языков, бибилиотек и tooling, memory safety. Дальше автор переходит к важности понимания своих зависимостей, а также работе с данными, где надо ограничивать доступ к чувствительной информации.

2. Define the system’s safe boundaries
Здесь автор выдает такую фразу "A lot of getting security “right” is just solid engineering. Security is a facet of quality", которая позволяет аргументировать внедрение хороших инженерных практик не только с точки зрения оптимизации темпа разработки или улучшения качества, но и с точки зрения рисков (как любят строить аргументы security специалисты). В этом же разделе автор говорит о том, что надо предвидеть масштабирование системы и думать о том, как она будет себя чувствовать при изменившихся условиях. Нам надо предвидеть потребность в реакции на инциденты наших ops/SRE команд. Дальше здесь опять идет речь про стандартизацию, но на этот раз паттернов и инструментов. Автор предлагает не создавать самим middleware, но предоставить командам список проверенных библиотек и сервис провайдеров, которые им стоит использовать. Плюс команды опять же должны знать про свои зависимости и понимать какие там могут быть ошибки. Если думать про уязвимости, то их надо классифицировать по тому, насколько атаку легко автоматизировать и масштабировать, а также насколько атака далека от целей атакующего. И с учетом этого можно приоритизировать устранение уязвимостей.

3. Observe system interactions across spacetime
Для построения безопасных и устойчивых систем нам нужна observability как с точки зрения топологии систем, так и с точки зрения изменений во времени. Дальше идет речь про ментальные модели, которые мы строим для понимания системы, а также про тестирование как систем, так и наших ментальных моделей. Автор топит за integration tests и ругает unit tests, но это кажется последствия профессиональной деформации. Дальше заходит речь про chaos engineering (например, есть такая книга), а потом про то, как это переходит в security chaos engineering. Автор рассказывает про стандартный цикл: постановку гипотезы, проведение экспериментов, анализ результатов и постановку задач на улучшение.

4. Feedback loops and a learning culture
Здесь автор говорит про важность обратных связей и обучения для улучшения ситуации. И тут на сцену выходит distributing tracing, который нам просто необходим:) Про тему с распределенным трейсингом можно прочитать отдельную книгу "Distributed Tracing in Practice"

5. Flexibility and willingness to change
В общем и целом, без желания меняться и менять систему не построить устойчивую систему. Это про адаптацию и про рефакторинг, про изменение кода наших систем и про простоту внесения изменений. Дальше автор рассказывает про статическую типизацию кода как помощь при рефакторинге:) Дальше автор переходит к модульности и появляются отсылки к coupling и тому, что модули формируют локальные границы. Причем isolation - это ключевое свойство, которое поддерживает system resilience. Дальше автор рассказывает про использование sandbox для исполнения опасного кода. Напоследок автор рассказывает как менять систему, используя паттерн "Strangler Fig", про которую рассказывал неплохо Мартин Фаулер почти 20 лет назад.

#Chaos #Engineering #SystemEngineering #SystemDesign #SoftwareArchitecture #Software

Энциклопедия менеджера. Алгоритмы эффективной работы 3rd edition (Fast Thinking Manager's Manual)

Недавно я купил стопку новых книг и там была книга издательства Альпина Паблишер с названием "Энциклопедия менеджера". Когда я ее открыл, то испытал чувство дежавю - я уже читал этот контент когда-то давно. Я начал вспоминать и понял, что новая книга была пятым изданием, а я в далеком 2007 году покупал третье издание этой книги, так как я хотел тогда понять как работают менеджеры, какие задачи они решают и вообще как строиться командная работа. В то время книга показалась мне скучной и муторной, а сами примеры не ложились на мой опыт - тогда я только начинал свой путь и был начинающим разработчиком. Прошло много лет и теперь впечатления совсем другие - я планировал пролистать книгу для того, чтобы освежить воспоминания и внезапно оказалось, что я начинаю ее перечитывать. В ней приведены слишком жизненные ситуации, которые отзываются у меня и в которых я зачастую действую похожим образом как рекомендуют авторы, но я пришел к этому сам а не следуя этим рекомендациям:)

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

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

P.S.
В этой книге нет специфики относительно разработки программного обеспечения, но кажется, что это и не требуется:)

#Management #Leadership #Career #SelfDevelopment

Ряд наград в мобильном приложении Тинькофф

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

P.S.
Это игра от создателей Монополии, 5 букв и других игровых проектов в нашей экосистеме. Ребята - молодцы и растут в плане сложности проектов и игровых механик, которые они уже научились использовать в таких играх. Я помню с чего все начиналось и что мы умеем сейчас - это небо и земля. А дальше будет еще круче:)

Resilience как архитектурная характеристика (из книги Continuous Architecture in Practice)

Я уже упоминал несколько раз книгу "Continuous Architecture in Practice" как достойный изучения труд по архитектуре (посты: 1 и 2). А сегодня я решил поделиться кратким саммари того, как авторы подходят к устойчивости и надежности систем. Для начала авторы определяются с терминологией

- A fault is an accidental condition that, if encountered, may cause the system or a system component to fail to perform as required.
- A failure is when a system or system component deviates from its required behavior. So, a fault is something that has gone wrong and that may cause a failure to occur.
- Availability is a measurable quality attribute of a system, defined as the ratio of the time when the system is available to the overall time when it could have been available.
- Reliability builds on availability and adds the constraint of correct operation, not just availability. A widely used definition of the reliability of software is “the probability of failure-free software operation for a specified period of time in a specified environment.”

Дальше авторы рассказывают про старый подход к обеспечению надежности, который обычно назывался high-availability и был основан на создании кластеров приложений, кластеров баз данных, использования cross-site репликации данных. Суть подхода была в том, чтобы в случае проблем с одной из нод в кластере, рабочая нагрузка могла переехать на другую ноду. А если падал кластер целиком, то можно было перенести нагрузку в другой кластер, который всегда стоял наготове (hot standby), в котором уже были все (или большинство) данных, благодаря репликации данных. И все было бы хорошо с этим подходом, удобным для разработчиков приложений, но
- эти механизмы повышения доступности запутанны и сложны в использовании
- зачастую они достаточно дорогие (даже в плане работающего вхолостую hot standby)
- failover процессы могут занимать много времени и требовать много работы
- во время восстановления система может быть полностью недоступна
В общем, эти high-availability подходы были расчитаны на монолитные on-premise системы и плохо подходят для распределенных микросервисных систем, которые могут быть развернуты как on-premise, так и в облаках.

Дальше авторы переходят к resilience как другому подходу для обеспечения reliability. В этом подходе каждая часть системы сама отвечает за свой вклад в обеспечение общесистемной availability за счет адаптации своего поведения к происходящим faults, например, распознавая сбои и используя, повторные запросы, автоматический перезапуск процессов, ограничивая распространение ошибки, правильно работая с latency запросов. В итоге, инженерам стоит знать и использовать такие механизмы обеспечения надежности, а не надеяться на технологии обеспечения high-availability из прошлого. Если использовать их правильно, то итоговая система будет более устойчива к ошибкам и сбоям и сможет более гибко приспособиться к проблемам во время эксплуатации систем.

Интересно еще рассмотреть эти подходы в контексте стандартных показателей
- Mean time between failures (MTBF) - среднее время наработки на отказ
- Mean time to recover (MTTR) - среднее время восстановления

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

#SRE #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #SystemDesign #SystemThinking

Алексей Савватеев | Теория игр вокруг нас

Отличное выступление от Алексея Савватеева про теорию игр. Алексей всегда отлично рассказывает, а тут он привел много примеров реальных ситуаций, которые рассмотрел с точки зрения теории игр. Модельки получились действительно интересными, а формат и подача материала очень хороши.
Мне особенно понравилось как разбирались модели:
- Теория игр в Талмуде
- Люксембург и Евросоюз
- Синдзо Абэ и Северная Корея
- Парадокс Брайеса
- Два парадокса Трампа
В общем, эти лекции можно воспринимать как вторую часть знаменитой фразы "Хлеба и зрелищ" - тем более лектор в рамках одной из игр с слушателями даже разыгрывает 2 шоколадки, которые неплохо подподают под первую половину данной фразы:)

P.S.
На тему теории игр еще можно почитать:
- "Теория игр в комиксах"
- "Теория игр. Искусство стратегического мышления в бизнесе и жизни"

#Thinking #Math #SelfDevelopment #PopularScience

Проектируем надежные системы - стоит ли игра свеч

Выступаю 21 сентября на конференции Сбера SmartDev с докладом про проектирование надежных систем. В своем выступлении я попробую задать и ответить на следующие вопросы
- Надо ли нам думать о надежности нашей системы и от чего это зависит?
- Как оценить надежность существующей системы?
- Почему надежность сложно добавить в существующую систему?
- Какие существуют принципы для проектирования надежных систем?
- Как выстроить процессы для достижения надежности?

P.S.
Регистрируйтесь на конференцию и приходите оффлайн или смотрите в онлайне, благо она бесплатная:)

#Architect #Architecture #Software #SoftwareDevelopment #SoftwareArchitecture #Conference

Обзор white-paper "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google"

Одна из моих областей интересов — это проектирования сложных систем и построение архитектурных процессов. Несколько месяцев назад я нашел эту статью от ребят из Google, которая вышла в 2023 году. В этой статье авторы (Qin Jia, Yuanfang Cai, Onur Çakmak) рассказывают про структурированный процесс редизайна крупной системы (Monarch) с использованием сценариев атрибутов качества (quality attribute scenario), а также с использованием моделирования системы при помощи UML. Я прочитал эту статью на выходных и готов поделиться кратким обзором.

#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #ExternalReview

The Engineering executive’s role in hiring от Will Larson

У Will Larson есть интересная рассылка, в которой он поднимает важные темы. И вот в конце августа он написал пост про то, как условные CTO и VP of Engineering могут участвовать в найме. Статья получилась большой, потому что это неотредактированная версия главы из новой книги Wll "The Engineering Executive’s Primer" (на сайте O'Reilly есть ранний доступ к этой книге, которую можно читать в процессе написания).

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

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

#Management #Leadership #Engineering #Software #SoftwareDevelopment