[SafeCode Live] Secure by design

Сходил недавно на запись выпуска SafeCode Live, где мы говорили про подход Secure by design (SBD) или конструктивную безопасность в разработке продукта.

Мы интересно пообщались на темы что это такое, зачем нужно, что делать "если уже все сделано небезопасно", как прокачаться в безопасности и так далее:)

На стрим нас было четверо
- Алексей Федулаев, ведущий подкаста, руководитель направления автоматизации безопасной разработки в Wildberries.
- Сергей Рогачев, руководитель отдела разработки безопасной платформы в Лаборатории Касперского.
- Екатерина Рудина, аналитик в Лаборатории Касперского. Работает в департаменте перспективных технологий в области исследования угроз, моделирования и оценки рисков.
- и автор этого канала

Достаточно непривычно было выступать на этот раз не в качестве эксперта, а скорее в качестве гостя, который заинтересован в том, чтобы практики security присутсвовали в SDLC и не в финальной стадии, а начиная с работы с требованиями, оценки рисков, проектирования решения и так далее. В итоге, я сам с удовольствием слушал других спикеров и даже добавил себе в reading list пару книг, что они рекомендовали, но начать решил с базовой «Software Security» от Mathias Payer, которую порекомендовал Сергей.

#Security #SRE #Software #SoftwareDevelopment #SoftwareArchitecture #DistributedSystems #Architecture

В этот понедельник мы провели первый стрим клуба Code of Architecture по новой книге “Continuous Architecture in Practice”. В этом выпуске мы обсудили темы
- важности архитектуры здесь и сейчас, а конкретно про вызовы, что стоят перед архитекторами, а дальше то, как continuous architecture поможет с ними. На самом деле нет, вызовы шли отдельно, а принципы continuous architecture отдельно
- про принятие и governing архитектурных решений, про атрибуты качества, технический долг, про циклы обратной связи (фитнес функции, continuous testing), модели и нотации для описания архитектуры, паттерны проектирования и архитектурные стили, концепцию архитектуры как потока принятия решений. Тут тоже все это не было объединено бесшовно сквозной идеей, что показывает, что спроектировать консистентную по содержанию главу у авторов не совсем получилось
Гостем стрима был Максим Смирнов — ИТ-архитектор и автор «Архитектура ИТ-решений».

На самом выпуске мы упоминали книги:
- Building Evolutionary Architecture - уже разбирали это в CoA
- Technology Strategy Patterns - уже разбирали это в CoA
- Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World - предыдущая версия книги, которая потом превратилась в Continuous Architecture in Practice
- серию книг Вернона - Addison-Wesley Signature Series (Vernon), которые интересны и куда входит Continuous Architecture in Practice

Отдельно мы обсудили то, что Continuous Architecture - это хороший нейминг для темы. Потом я зашел на сайт continuous-architecture.org и нашел набор документов, которые застолбили тему непрерывной архитектуры за авторами:
- манифест по типу agile manifesto
- фреймворк в виде набора инструментов для continuous architecture в организациях
- инструкция как внедрять ее в организациях

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

YaTalks - Как формировать структуру команд под запросы бизнеса

6 декабря в Москве я буду выступать на конференции Яндекса с докладом-саморефлексией примерно с такими тезизами

В последние годы Tinkoff растет взрывным образом, что приводит к большим количествам изменений: организационных, продуктовых и инженерных. Я с компанией уже семь лет и не просто застал времена перемен, а участвовал во многих из них со стороны IT, причем про многие из них я рассказывал публично на конференциях и в своих статьях. Но в этом докладе я хотел бы вернуться к основам и поговорить про те принципы дизайна команд и управленческой структуры, которые помогали мне все это время. Плюс я хотел бы рассказать примеры того, как я использую их сейчас в редизайне структуры своего подразделения почти в тысячу человек:)

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

#Management #Conference #Processes #Architecture #Project #Engineering #SoftwareDevelopment

Несведущий маэстро (The ignorant maestro: How great leaders inspire unpredictable brilliance) - I

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

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

Существует ли универсальное звучание, подходящее всем организациям на каждой стадии развития?

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

Часть 2. Три мелодии лидерства
Автор предлагает свой рецепт из трех ингредиентов
1. Блестящее неведение
Здесь идет речь про философию Жака Рансьера, который написал книгу "Невежественный учитель" и популяризировал мысль педагога 19 века Жакото

Невежда может научить другого невежду тому, чего не знает сам

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

Лишь человек, который не знает, способен научиться чему-то неожиданному и добиться непредсказуемого

2. Не бойтесь пустот
Глава начинается с цитаты великого пианиста, Артура Шнабеля

Я умею играть ноты не лучше и не хуже других пианистов, но паузы между нотами - ах вот где искусство

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

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

В следующем посте я расскажу про третью часть книги, где автор говорит про стили лидерства 6 великих дирижеров.

P.S.
Меня давно интересовало как дирижеры и хореографы управляют своими коллективами и как это связано с управлением software engineering. Несколько лет даже написал статью про это:)

#Management #Processes #Leadership #Self

Code of Architecture - Continuous Architecture in Practice - II

Сегодня в 18:00 по Москве мы обсудим третью и четвертую главу книги Continuous Architecture in Practice. Эти главы посвящены архитектуре данных и безопасности.
- В третьей главе авторы вспоминают про DDD в контексте ubiquitous language и bounded contexts для проектирования самой доменной модели, дальше про polyglot persistance в разрезе использования sql/nosql решений, вспоминают про модели консистентности (по-факту, только про eventual consistency), кратко пробегаются по event sourcing, а дальше приходит к концепции data ownership и отгрузке данных для построения аналитических моделей, ну и напоследок обсуждают вопросы эволюции схемы в sql и nosql решениях.
- В четвертой главе наступает очередь безопасности и авторы говорят про основные вызовы, вспоминают триаду CIA (Confidentiality, Availability, Integrity), рассказывают про идентификацию и приоритизацию угроз, а в конце доходят до shift-left security.

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

#Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management

Yandex Platform Engineering

Крутой ресурс с описанием технологий и команд отдела Yandex Platform Engineering, который делает инфраструктуру для разработки и эксплуатации продуктов Яндекса.
Я первый раз вижу настолько круто сделанную страничку с описанием разных команд, их продуктов, а также технические параметры: основные языки, фреймворки, базы данных и других параметров, важных для разработчиков. И хоть я не собираюсь устраиваться в Яндекс, но мне было интересно побродить по странице и вдохновиться относительно того, как надо описывать свои команды, чтобы инженеры хотели попасть в них:)
Обычно страничка каждого продукта содержит как минимум следующие пункты
- важность продукта для пользователей (обычно других инженеров)
- инженерные вызовы, что стоят перед командой с объяснением почему именно так
- процессы, что приняты в команде - часто тут приводится принцип "you build it, you run it" с упоминанием про дежурства
- как выглядит команда и ее взаимодействие

P.S.
Думаю, что этот подход и нам стоит взять на вооружение

#PlatformEngineering #Engineering #Software

How to Improve Developer Productivity • Jez Humble • YOW! 2020

Хорошее выступление Jez Humble на конференции Yow, в котором он рассказывал кратко про продуктивность разработки. Jez является соавтором книги "Accelerate" и это выступление выглядит как краткое саммари влиятельной книги, про которую я рассказывал раньше в постах 1, 2, 3.
Выступление начинается с плохих метрик продуктивности:
- lines of code - когда-то это была популярная мера, но теперь все понимают, что лучше меньше, да лучше
- velocity - это относительный показатель уровня команды, который нельзя использовать для сравнения команд между собой, а также им легко манипулировать при желании
- utilization - если гнаться за утилизацией, то мы сталкиваемся с законом Литтла и попадаем в ситуацию, когда очередная задача может примерно бесконечность находиться в очереди
Дальше Jez переходит к рассказу, а на что же надо обращать внимание и мы получаем, что продуктивность это
- team metric - результаты приносят команды, а не люди
- system-level outcomes - стоит смотреть на системные результаты, а не локальные
- outcomes, not output - надо максимизировать результаты, а не количество сделанных задач
Дальше на сцене появляются DORA метрики, разбитые по двум категориям
— Software delivery performance tempo — сюда входит delivery lead time и deployment frequency
— Software stability — сюда входит mean time to recover и change fail rate
И Jez разбирает их в деталях. Ну и напоследок Jez говорит про культуру и вспоминает
- исследования Веструма, про которые я уже писал. Там была речь про три типа культур: патологическую (pathological), бюрократическую (bureaucratic), производительную (generative)
- исследования Aristotle, которое проводил Google для своих команд. Главным вопросом было "What makes a team effective at Google?". Топ-1 фактором оказалось Psychological safety. Я уже рассказывал про это исследование.

#Management #Engineering #Software #SoftwareDevelopment #SRE #Devops #Leadership #Processes #PlatformEngineering

День Тинькофф в МФТИ

4 декабря схожу в гости на Физтех на день Тинькофф, чтобы рассказать студентам про современные подходы к разработке софта. Интересно, что лет 20 назад я был на втором курсе МФТИ и думал где и как работать так, чтобы совмещать это с учебой. А теперь я могу вернуться в альма-матер и рассказать про то, где и как можно стать крутым SDE (software development engineer). Конкретно для ребят с физтеха я планирую рассказать
- Как выглядит процесс работы в кросс-функциональной командах, который они увидят, если выйдут в компанию с поставленными процессами разработки
- Как у нас организованы команды разработки - тут я расскажу про топологию команд, условно про stream-aligned команды и платформенные команды
- Приведу примеры технологических и бизнесовых продуктов и расскажу где там сложность (распределенные системы, высокая нагрузка, большая столожность домена, ...)
- Как выглядят отбор SDE с рынка с опытом и как выглядит отбор на стажировки студентов из университетов
- Поговорю про выбор инструментов под задачи (языка и тулинга) - здесь основной акцент сделаю на том, что хорошая база CS (computer science) позволяет "программировать с использованием языка, а не на нём", а к этому и надо стремиться, о чем говорил еще Стив Макконел в книге Совершенный Код (Code Complete), про которую я рассказывал раньше

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

#Conference #Software #SoftwareDevelopment #Management #Leadership #Engineering

Тинькофф что-то про меня знает:)

Как департамент утилизации CPU превратился в департамент экономии железа, выдерживающий нагрузку в 1 млн RPS

Хорошая статья от Ozon на тему кэширования на примере создания сервиса product-facade, который будет единым кешом над всеми мастер-системами в Ozon. Сервис получился нагруженным (1 mln rps, 350 Gb/s в пике на раздачу). Интересно почитать про различные стратегии работы с кешом по мере нарастания изощренности
- lazy caching (с чего все начиналось) и дальше вопросы инвалидации кеша с версионированием, тегами, TTL, событиями из Kafka для инвалидации
- read-through caching
- write through caching
Дальше интересная часть про выбор локального или внешнего хранилища кешей и отчего это зависит, тут прямо хорошо разобраны дизайн решения и плюсы и минусы каждого подходов и как и для чего их комбинировать. А дальше хорошо про борьбу за hitrate и стратегии вытеснения кеша (LRU, LFU, Segmented LRU) и что делать с thundering herd problem. И напоследок немного про то, как кешировать решение полностью обмазанное кешами:)

В конце авторы выдают хороший чеклист из вопросов, которые надо задать себе перед тем, как начать кешировать

- Безопасно ли использовать кэшированное значение?

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

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

#Software #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #Management

В этот понедельник мы провели второй стрим клуба Code of Architecture по книге “Continuous Architecture in Practice”. Мы говорили про архитектуру данных и безопасность, упоминая очень много интересных источников. Ниже перечислены все эти рекомендации

Подкаст "Издержки Поддержки"

Это интересный подкаст про благотворительность в России без сердобольности и жалости от Тинькофф и подкаст-студии «Гласно». Мне было интересно послушать его потому, что моя жена вовлечена в благотворительность, а я про эти вопросы раньше редко задумывался. Уже записано 4 из 5 эпизодов, а последний выпуск выйдет 28 ноября, ниже я привел описание каждого выпуска и ссылки

- 1: «Сколько может гореть волонтер, пока не выгорит, и зачем?»
Зачем люди становятся волонтерами? Синдром спасателя, компенсация психологических травм или же просто «социальная плюшка»? Выясняем вместе с волонтером, психологом и директором фонда.
- 2: «Когда ломается эмпатия: самые сложные сферы НКО»
Что делать тем благотворительным фондам, которые должны обращать наше внимание на эмоционально тяжёлые ситуации? Особенно, если это касается помощи тем людям, которым, кажется, уже невозможно помочь? Говорим о неизлечимо больных людях, стигматизации бездомных и поддержке трудных подростков.
- 3: «Зачем спасать животных, когда страдают люди?»
В интернете видео со спасением животных всегда набирают огромное количество просмотров, лайков и доброжелательных комментариев, но почему-то в реальной жизни зооволонтёрство — это одна из самых токсичных сфер благотворительности. Ненависть, мошенничество и запредельная жестокость — это обыденность фондов, помогающих животным, и поэтому все так опасаются об этом говорить.
- 4: «Притворяться правильными: зачем сотрудничают богатые и фонды?»
Правда ли, что богатые люди помогают фондам ради обеления репутации, или же это делается для других целей? Говорим о знаменитостях России в НКО и закрытых вечерах для дарителей. А также рассказываем, что доступно всем и какие акции и концерты существуют сейчас.
- Эпизод 5: «Герои и злодеи: как помогать, когда тебе не верят?»
Недобросовестность одних, и как следствие, недоверие к другим — это те самые издержки поддержки, с которыми вынуждены жить благотворительные организации сегодня. Обсуждаем болезненные вопросы репутации и доверия.

#Charity

Участие в передаче "Цифровизация бизнеса"

Первый мой опыт участия в телевизионной программе теперь доступен для просмотра - вышла серия передачи "Цифровизации бизнеса", в которой я ходил в гости к Максиму Морозову, ведущему паредачи, а также генеральному директору Aston. Мы обсудили разные темы:
- Про то, как работать в крупнейшем цифровом банке России
- Какие задачи стояли перед нами в последнее время
- Какие технологии влияют на финансовую индустрию (тут нет ничего нового: блокчейн + LLMs)
- Зачем нам нужно RnD направление и как мы превращаем исследования в технологические продукты как для себя, так и выпуская их на рынок
- Немно про то, как мы нанимаем сотрудников и как растим их сами при помощи Тинькофф Образования
- А закончили обсуждением моих активности на ниве выступлений, написания статей, ведения этого канала

#Management #Conference #Leadership #SelfDevelopment