Сегодня вечером в 18:00 по Мск будет шестой выпуск клуба "Code of Architecture" по книге "Распределенные системы" ван Стина и Таненбаума, в котором мы обсуждаем главу про именование. Предыдущие выпуски были посвящены общему обзору книги, обсуждению архитектуры, процессов, коммуникаций, координации, а теперь мы дошли до обсуждения следующих важных вопросов
 - Зачем нужны имена, идентификаторы и адреса
 - Что такое плоское именование (flat naming). Здесь в качестве примеров рассмотрим Distributed Hash Tables
 - Что такое структурированное именование (structured naming). Здесь в качестве примеров рассмотрим работу DNS и Unix FileSystems
 - Что такое основанное на атрибутах именование (attribute-based naming). Здесь вспомним про LDAP
 - Что такое named-data networking

Встречаемся на ютуб-канале IT's Tinkoff.

#SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software #CoA

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

Chaos Engineering. Building Confidence in System Behavior through Experiments

Эту книгу я прочитал лет 5 назад и мне она понравилась: отличная обложка и очень здравый и взвешенный подход для работы с комплексными системами

Книга начинается с главы "Зачем заниматься инженерией хаоса" и ее достаточно для того, чтобы определиться стоит ли читать книгу дальше. В первом абзаце авторы рассказывают о том, что Chaos Engineering используется для эмпирического исслледования поведения систем при помощи экспериментов. Чем-то этот подход напоминает мне лабораторные работы по физике/химии в университетские времена:) Основная цель эксперииментов узнать о потенциальных слабостях системы заблоговременно, а не в момент, когда они приводят к реальным проблемам. Хаос иненерия кардинально отличается от тестирования системы, т.к. в тестировании есть специфичные условия и ожидается специфичное поведение, тесты обычно имеют бинарную природу. В итоге, тесты не дают нам новой информации о системе.

В свою очередь, хаос инженерия в свою очередь при помощи экспериментов поззволяет нам лучше понять систему и узнать об особенностях ее функционирования.
В этой же главе рассказывается о пререквизитах для Chaos Engineering: для определения степени готовности вашей организации к использованию Chaos Engineering вам требуется ответить на 1 вопрос:"Достаточно ли устойчива ваша система к событиям реального мира, например, отказам сервисов или пикам сетевых задержек (network latency)".
Если ответ "нет", то до вы знаете что вам стоит сделать до того, как изучать данную книгу:) Думаю, что большая часть читающих книгу отсеивается на данных пререквизитах:)
Но представим, что мы ответил "Да" - в этом случае вы попадаете в прекрасный мир chaos engineering, который помогает контролировать сложность систем и спать спокойно:)
Если тема вас заинтересовала, то предлагаю вам самим ознакомиться с этой книгой:)

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

Agile Patterns

В свое время читал перечень этих паттернов в карточке с DZone, плюс есть сайт agilepatterns.org

Если кратко, в первой половине статьи с DZone автор выделяет шаблоны, которые помогают организовывать разработку по agile. Про них все всегда рассказывают и поэтому я не буду их здесь перечислять. А вот на последних страницах автор рассказывает об антипаттернах, которые могут пох...рить всю нашу работу по выстраиванию процессов:)
Среди таких антипаттернов присутствуют
- Cherry Picking - выбор членами команды самых "вкусных" задач из беклога вместо самых приоритетных
- Death March - продолжение проекта, который уже не нужен, но на который потратили много сил и его жалко закрыть
- Disguised Project - проект, который заказчик пытается пропихнуть как рутинные задачи
- Micromanagement - ну тут все ясно:)
- Unbounded Timebox - неопределенные границы для завершения проекта
- Undefined Done - ху..к-х..к и в продакшен:) и куча техдолга на выходе
- Unlimited WIP - неограниченный объем задач в работе
- Unresolved Proxy - много заказчиков без одного ответственного за продукт
- Waterscrumfall - гибрид из waterfall и scrum, признан нежизнеспособным в открытой природе:)

В общем, хорошая статья и читается легко:)

#Management #Processes #Scrum #Kanban #Agile

От основ к созданию роботов

Лет 5 назад я купил эту книгу для обучения сына премудростям создания роботов. Я ее конечно прочитал, но воплотить план обучения в жизнь не получилось, но это не проблема книги, которая отлично написана и оформлена иллюстрациями. Её приятно даже просто пролистать.Если переходить к сути книги, то авторам удалось весело и с простыми практическими занятиями раскрыть заявленную в названии тему:)
В первых главах были описаны разнообразные роботы и дана качественная характеристика, отличающая робота от радиоуправляемой игрушки:)
Дальше авторы рассказали о:
- программировании алгоритма работы робота
- булевой логике
- датчиках как органах чувств роботов
- беспроводной связи
- adruino и управления моторами при помощи ШМИ
В общем, книга действительно интересная и подходит для практических занятий робототехникой с сыном:)

#Robotics #ForKids #SoftwareDevelopment #Engineering

Software Engineering для Финтех Школы

Мы в компании уделяем достаточно много сил и времени обучению. Мы учим как сотрудинков внутри, так и будущих сотрудников, начиная со школьной скамьи и продолжая в университете. В этом году мне надо было записать для Финтех Школы лекцию про облачные вычисления и я решил посмотреть как мои коллеги рассказывали о Software Engineering в предыдущих циклах обучения. Так я наткнулся на доклад Игоря Маслова, директора базовых технологий, который он читал для студентов в 21 году. Доклад мне понравился тем, как Игорь разбирает эволюцию подходов в разработке софта и демонстрирует, что это очень динамичная сфера, в которой подходы постоянно развиваются и то, что было нормой еще 10 лет назад может к текущему моменту безвозвратно устареть. Ну и из этого обзора видно, что наша молодая дисциплина идет от ремесленного к инженерному подходу, обрастая практиками, которые позволяют обеспечить повторяемый результат хорошего качества.

P.S.
Подробнее про наши образовательные программы можно прочитать на сайте https://fintech.tinkoff.ru/

#SoftwareDevelopment #Software #Engineering #SystemEngineering #Processes

В этот понедельник мы провели шестой стрим клуба Code of Architecture по книге “Distributed Systems”, в котором мы обсудили вопросы именования. А точнее мы поговорили про
- адреса, идентификаторы и имена
- плоское именование, влючая распределенные хеш таблицы и consistent hashing
- структурное именование, включая unix filesystem и DNS
- attribute-based naming, включая триплеты RDF из семантического веба и LDAP как комбинацию структурного и attribute-based подхода
- name-data networking, экспериментальный подход, который хочет занять место протокола IP в современном интернете

Гостем стрима был
- Алексей Квак, руководитель разработки из Тинькофф

Артефакты с этого стрима доступны по ссылкам
- Статья с кратким обзором
- Запись стрима
- Miro доска с презентацией

#SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software #CoA

Writing an engineering strategy

Интересная статья про инженерную стратегию от Will Larson, автора книг An Elegant Puzzle (про engineering management, я про нее как-то рассказывал) и Staff Engineer (про высокоуровневых SDE, у меня есть обзор этой книги в двух частях: 1, 2).
В этой статье автор рассказывает про то, как писать engineering strategy, являясь engineering executive, используя структуру которую предложил Richard Rumelt в книге "Good Strategy, Bad Strategy". В этой структуре 3 составляющих:
1. Diagnosis - объяснение в чем вызов и корневая проблема, которую мы решаем
2. Guiding policies - подходы, которым стоит следовать для решения вызовов. Эти руководящие policies могут быть как явными, так и неявными компромиссами (tradeoffs) между вариантами действий.
3. Coherent actions - набор действий, которые направляются принципами для решения challenge. Эта самая важная часть стратегии.

Дальше автор рассказывает про
- Процесс написания
- Когда ее стоит писать
- Что делать с отсутствующими бизнесовой и продуктовой стратегией, которые должны учитываться в инженерной стратегии
- Как структурировать руководящие принципы
- Как поддерживать нужный уровень руководящих принципов
- Как сформировать перечень конкретных действий
- Почему стратегия - это про top-down approach
- И как начать писать стратегию

#Strategy #Engineering #Management #Leadership #Process #SystemEngineering

Руководитель разработки медиапроектов Тинькофф

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

Интересно, что само направление медиа для меня не чужое, так как еще до Tinkoff я успел принять участие в разработке медиа-проектов, будучи руководителем команд разработки в Woman.ru и Banki.ru. А в первый день выхода на работу в Тинькофф я познакомился с первым программистом Тинькофф Журнала (Т—Ж), так как мы одновременно устраивались на работу. Дальше я никогда напрямую не отвечал за Т—Ж, но часто помогал с консультациями и выделением времени инженеров из моих команд. Но теперь настало время платформизировать Т—Ж и сделать его основой всех наших медиа.

В итоге, я ищу опытного руководителя, который возьмёт на себя роль технического директора медиапроектов Тинькофф: он возглавит команду отдел из 40 инженеровспециалистов, запустит новые направления и выстроит процессы. Сейчас в разработку медиапроектов входит три больших продукта:
- Журнал
- Помощь
- Бизнес-секреты
- Помимо этого есть и другие продукты поменьше: образовательные Учебник и Школа бизнеса, блоги продуктов, платформа для медиа. Продукты представлены в вебе и мобильных приложениях. Всё это поддерживают и развивают семь продуктовых команд и две сервисные. Продуктовые команды кросс-функциональные, в их состав кроме технарей входят продакты, дизайнеры, редакторы и другие специалисты. Сервисные команды — тестирование и инфраструктура.

В планы медиапроектов на 5 лет входит
— Создать большое сообщество, где пользователям будет легко создавать и загружать контент в разных форматах: видео, изображения, длинные и короткие статьи, а модераторам — проверять его
— Прокачать админку, чтобы редакторы сами выпускали статьи и публиковали другой контент без участия специально обученных верстальщиков.
Помимо этого надо будет
— Разработать собственную CMS на основе текущих наработок Т—Ж, чтобы запустить новые контентные проекты и пересадить на неё существующие.
— Запустить и поддержать 10 новых контент-проектов. Сделать всё так, чтобы каждый проект не был ограничен возможностями платформы, а мог по необходимости расширяться собственной функциональностью.

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

В моих глазах идеальный кандидат:
— Несколько лет руководил отделом или командой разработки больше 30 человек.
— Работал в крупной продуктовой компании. В идеале, ещё и успел поработать в медиа.
— Умеет оптимизировать процессы: ускорять релизы, повышать пропускную способность команды.
— Имеет широкий технический и архитектурный кругозор. Знаком с концепцией микрофронтендов, эволюционного дизайна, монолитов, сервисов, микросервисов, чистых функций и вот этого всего. В идеале, уже однажды спроектировал и воплотил переход технического решения из продуктового в платформенное.
— Знаком с большей частью стэка команды: React, React Native, FastAPI, Postgres, Redis, Docker, Kubernetes.
— Умеет планировать на разные горизонты: от спринта до нескольких лет. Способен синхронизировать эти планы между бизнесом и технарями. Различает роадмапы и бэклоги, CJM и user story.

P.S.
Если вы считаете, что подходите на эту позицию, то пишите мне в личку.

#Vacancy #Engineering #Management #Leadership

Безопасность разработки в Agile-проектах (Agile Application Security: Enabling Security in a Continuous Delivery Pipeline)

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

В самом начале идет краткий экскурс в современную разработку в главах:
Глава 2. Элементы гибких методик
Глава 3. Революция в методах разработки - присоединяйтесь!
Глава 4. Работа с существующим жизненным цилком разработки
Эти начальные главы дают настолько хороший экскурс, что они будет полезны не только безопасникам, но и самим разработчикам, работающим в рамках гибких подходов, т.к. иногда следование процессам преващается в карго-культ или формопоклонничество как это называл Фейнман:) Поэтому иногда стоит вспоминать, что важен не сам процесс ради процесса, а те результаты, которые он помогает достигать.

Дальше идут главы про безопасность
Глава 5. Безопасность и требования. Тут речь идет о том, что безопасность - это просто еще одна область нефункциональных требований и ее стоит встривать в процесс работы над системой с самого начала как, например, вопросы производительности конечного решения или его удобства
Глава 6. Гибкое управление уязвимостями. Тут речь идет о том, как относится к уязвимостям, как учитывать их и как планировать их устранение, а также как связано тестирование и безопасность
Глава 7. Риск для гибких команд. Вся глава посвящена основам риск менеджмента в контексте вопросов безопасности. Если вы уже знакомы с этой областью знаний, то сложно будет найти что-то новое
Глава 8. Оценка угроз и осмысление атак. Одна из самых содержательных глав по безопасности:)
Глава 9. Построение безопасных и удобных для пользователей систем. Здесь рассматриваются варианты проектирования безопасности так, чтобы она приводила в итоге к продукту, которым нельзя пользоваться, т.к. средства безопасности рушат весь user experience
Глава 10. Инспекция кода в интересах безопасности. Здесь рассматриваются варианты code review причем с точки зрения того, как их использовать правильно, чтобы повысить безопасность конечного решения
Глава 11. Гибкое тестирование в безопасности. Здесь речь о том, как тестировать код, инфраструктур и CI/CD пайплайн в интересах обеспечния безопасности. Авторы упоминают несколько инструментов, которые могут быть полезны практикующим специалистам
Глава 12. Внешние инспекции, тестирование и рекомендации. Лучше всего про содержание этой главы говорит следующая фраза, завершающая главу: "Если вы не собираетесь использовать внешние инспекции, чтобы учиться у экспертов, то только зря тратите их время и свои деньги"
Глава 13. Эксплуатация и безопасность. Здесь рассматриваются вопросы мониторинга и обнаружения вторжений, реакций на инциденты, защиты CI/CD пайплайно и работы с секретами:)
Глава 14. Сообщение нормативным требованиям. Здесь расматриваются 2 подхода:
1. Подход на основе правил (Пример: PCI DSS)
2. Подход на основе результатов (Пример Reg SCI)
Эту главу полезно прочитать, чтобы понять разницу в этих подходах, а заодно ознакомиться с человеческим описанием того, что за правилы описаны в PCI DSS, которые часто поминауются всуе по поводу и без:)
Глава 15. Культура безопасности. Очень хорошо про культуру. Замечательно про "тяни, а не толкай" и принципы эффективности:
1. Содействуй, а не блокируй;
2. Прозрачная безопасность;
3. Не ищите виноватых;
4. Масштабировать безопасность, усиливать фланги;
5. Кто - не менее важно, чем как
Глава 16. Что такое гибкая безопасность. Здесь каждый из 4-х авторов книги рассказывает свою историю и делится тем, как пришел к вопросам безопасности в разработке и кристализует свои мысли относительно темы книги

#Sec #Security #Agile #Processes #Software #SoftwareDevelopment #DevSecOps

Сегодня вечером в 18:00 по Мск будет седьмой выпуск клуба "Code of Architecture" по книге "Распределенные системы" ван Стина и Таненбаума, в котором мы обсуждаем главу про консистентность и репликацию. Предыдущие выпуски были посвящены общему обзору книги, обсуждению архитектуры, процессов, коммуникаций, координации, именования, а теперь мы дошли до обсуждения следующих важных вопросов
- Для чего нужна репликация и какие проблемы она решает (производительность и надежность), а какие приносит с собой (сложность поддержки консистентности)
 - Какие модели консистентности бывают: дата-центричные и клиенто-центричные
 - Какие бывают дата-центричные модели консистентности (sequential, causal, eventual, continuous)
- Какие бывают клиенто-центричные модели консистентности (monotonic reads, monotonic writes, read your writes, writes follow reads), а также рассмотрим пример с ZooKeeper
 - Как управлять репликами (replica management)
 - Какие протоколы косистентности бывают
А также напоследок рассмотрим как работает кеширование и репликация в современном Web

Гостями стрима станут наши коллеги — Дмитрий Гаевский и Виталий Кондратов. Дмитрий занимается разработкой dev to dev-решений на больших масштабах, создает сложные RnD-решения и проектирует event-driven-системы. Виталий — архитектор в отделе базовых технологий. Он разрабатывает и улучшает базы данных и инфраструктуру для их эксплуатации.

Встречаемся на ютуб-канале IT's Tinkoff.

#SoftwareArchitecture #DistributedSystems #Architecture #SystemDesign #Software #CoA

Список материалов для моего выступления сегодня на Teamlead Conf 2023 "Как нанимать технических руководителей "

Наем инженеров обсуждается на конференциях довольно часто. Кто-то рассказывает про то, как нанимает за одну встречу, а другие говорят про свои многоэтапные интервью. А вот про наем технических руководителей (teamlead, engineering manager, director of engineering) рассказывают гораздо реже. В этом докладе я исправляю эту несправедливость и в конце делюсь списком рекомендованных материалов, представленных ниже. Отдельно отмечу, что расшифровку доклада я тоже опубликую сегодня, но уже после выступления:)

Management and Leadership
- Книга "The Manager's Path" и саммари в трех частях: pre-manager, manager, engineering director
 - Книга "An Elegant Puzzle: Systems of Engineering Management" и ее краткий обзор
 - Книга "A Seat at the Table: IT Leadership in the Age of Agility" и ее краткий обзор
 - Книга "The Art of Leadership: Small Things, Done Well"
 - Книга "Technology Strategy Patterns"
 - Книга "Staff Engineer" и обзор в двух частях: 1 и 2
 - Мой доклад "Эволюция роли технического руководителя от инженера до CTO", в нем есть куча рекомендаций по изучению
 - Мой доклад "SOLID'ный тимлид, или основы менеджмента для технарей"

Processes and projects
- Книга "Team Topologies" и ее обзор в 3 частях: teams as means of delivery, team topologies that work for flow, evolving team interactions for innovation and rapid delivery
 - Книга "Remote Team Interactions Workbook"
 - Книга "More Effective Agile: A Roadmap for Software Leaders"
 - Книга "Making Work Visible"
 - Книга "Digital Transformation Game Plan"
 - Моя статья "Про управление проектами и продуктами"

HR
-Книга "Who : Solve Your #1 Problem"
 - Книга "The CEO Next Door"
-Статья про performance review

Technical excellence
-Статья про System Design Interview в общем
 - Статья про то, как мы оцениваем System Design Interview
-Статья о том, как подготовиться и пройти System Design Interview
 - Публичное System Design Interview на C++ Russia 2022
 - Публичное System Design Interview на конференции ArchDays 2022
 - Статья про то как развиваться если ты уже Senior developer
 - Стать про Troubleshooting Interview в Tinkoff
 - Статья со списком книг о проектировании программного обеспечения

#Management #Leadership #Processes #Conference #SystemDesign #Engineering

Как нанимать технических руководителей — выступление на Teamlead Conf 2023

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

#Management #Leadership #Processes #Conference #SystemDesign #Engineering

Балет "Зимняя Сказка" в Большом Театре

Был вчера с женой на этом балете и нам все понравилось. Мы сидели во втором ряду партера и могли наблюдать не только хореографию артистов балета, но и работу дирижера, а также его оркестра. За работой этих слаженных коллективов было очень интересно следить с учетом того, что я как-то писал статью про подходы оркестровки и хореографии в мире менеджмента разработки ПО:)

Сам балет был в трех действиях, наполненных драматическими событиями, которые не очень-то были похожи на сказку, а если и были, то на какую-то мрачную. Правда, финал был максимально похож на happy end:)

В общем, если вам нравится балет, то вероятно вам понравится эта постановка на основе одной из поздних пьес Уильяма Шекспира.

#Culture #Management #Processes #Agile