Code of leadership #15 - Interview with Roman Lebed about Information security

В пятнадцатом выпуске подкаста "Code of Leadership" я пообщался с Романом Лебедем, архитектором из департамента информационной безопасности Тинькофф. До Тинькофф Роман руководил командой Red Team и занимался прикладными исследованиями в области безопасности приложений и операционных систем. В этом интервью мы обсуждаем подходы к безопасности в современных технологических компаниях. За 50 минут мы успели рассмотреть следующие моменты

- Как выглядит работа security архитектора в Тинькофф
- Требования к экспертам безопасности
- Как выстроено взаимодействие с командами разработки
- Какие подходы к безопасности существуют в Тинкофф
- Роль архитектора в команде
- Метрики безопасности
- Об "информационной безопасности" как профессии
- Обучение и развитие SDE (software development engineers) и shift left подходы
- Рекомендации для начинающих специалистов

P.S.
У Романа есть свой канал, посвященный безопасности @offensive_thread, на который можно подписаться, а также можно почитать книги, которые он рекомендовал
- Building secure and reliable systems - я про нее уже как-то рассказывал
- How to Linux works
- Android Internals::A Confectioner's Cookbook
- MacOS and iOS Internals (3 тома)
- Компьютерные сети (Таненбаум и ко)

Также у Ромы есть ряд интересных вакансий в его команды
- Архитектор ИБ/ Security Engineer & Architect (SEAR) в команду защиты Core Services
- AppSec TechLead в команду защиты периметра
- DevSecOps инженер в команду защиты периметра
- Разработчики Golang в команду VMP (Vulnerability Management Platform)

Если одна из вакансий вам интересна, то пишите Роме (@Ziv00s3)

#Infosec #Leadership #Architecture #Software #Processes #ProductManagement #Management #Security

Ты уволен. С уважением, ChatGPT (Выпуск подкаста "Карты, деньги и продукт")

Интересный выпуск подкаста "Карты, деньги и продукт", в котором мои коллеги обсуждают влияние искусственного интеллекта на различные профессии, но преимущественно в продактов. Очень интересно слушать гостя, Витю Тарнавского, директора AI Центра Tinkoff, который рассказывает о текущих возможностях AI, а также про его перспективы. Если сократить, то ребята затронули вопросы
- Как AI повлияет на разные профессии - тут больше всего эффекта на digital профессии, так как они уже оцифрованы. А вот профессии из реального сектора сложнее автоматизировать. Для того, чтобы не оказаться на профессиональной обочине надо прямо сейчас пробовать и применять AI инструменты для помощи в своей работе, например, copilot для написания кода, тестов, ...
- Не во всех областях LLMs можно использовать эффективно - у сетей есть галлюцинации и иногда это не ок (но для условной болталки это не проблема)
- В Тинькофф мы активно внедряем технологии искусственного интеллекта для автоматизации работы продуктов и сервисов. Из свеженького можно почитать нашу новость про вселенную ассистентов от 25 апреля 2024 года
- Можно пробовать использовать AI для помощи в принятии решений - например, подбор рецептов по продуктам из холодильника или прогнозированию расходов на фастфуд
- Другая крутая тема - это использование AI для помощи в корпоративном управлении. Условно в большой корпорации всегда есть проблемы с управляемостью (централизацией/децентрализацией) и стоимостью аппарата управления. Примерно про это я писал в посте про developer productivity, называя это подходом сверху-вниз
- Все бегут в сторону AI, потому что есть ожидание, что он может приносить деньги, автоматизируя процессы и создавая новые прогрессивные продукты. Витя упоминает конкретные примеры
- Ну и в финале этой серии гость и ведущие выражают надежду на наступление "пелевинских времен", когда технологии будут помогать в жизни и трансгуманизм станет реальностью.

#AI #ML #Leadership #ProductManagement #Productivity #Management

YAC 2023 - Нейросерия (1 сезон, 1 эпизод)

Интересный формат Yet another conference, которую лет 10 назад я посещал лично. А теперь это сделано в виде сериала, первая серия, которого посвящена трансформационным изменениям от LLMs, причем показано как они влият на продукты самого Яндекса.
- Рассказывается про то, как новая Алиса стала умнее общаться с пользователями - сначала с помощью навыка "Давай придумай", а потом и в обычном режиме
- Про связь LLMs и поиска - мы все видели как ChatGPT встраивался в Bing и вот недавно Яндекс выкатил Нейро
- Про этические аспекты, включая галлюцинации и цензуру, например, на нецензурную лексику
- Про визуальные продукты и Шедеврум от Яндекса
- Про суммаризацию статей и видео в Yandex Browser (удобная штука, которая позволяет экономить время)
- Про то, как LLMs помогают преодолеть проблему чистого листа в контентных сервисах (написать болванку объявления, отзыва, ответа на обращение, письма, ...)
- Ну и про будущее AI, где будет распространено создание персональных ассистентов для разных сфер - аля экосистема персональных помощников, которую мы запустили в Тинькофф

#ML #AI #Software #DataScience

Чистый дизайн (Tidy First?) - Part II - Очистка (Tidyings)

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

В итоге автор предлагает следующие подходы
- Охранные выражения (guarding clauses) - вынос в начало функции начальных выражений, которые надо учитывать и ранний возврат при их наступлении из функции
- Мертвый код (dead code) - его просто надо удалить (если он понадобится, то его можно будет восстановить из системы контроля версий)
- Нормализация симметрий (normalize symmetries) - если кратко, то надо использовать консистентные подходы по всему коду, например, подход к определению и инициализации переменных. Тут могут помочь линтеры или подходы к readability, как в Google (про которые я писал раньше в посте про measuring engineering productivity)
- Новый интерфейс, старая реализация (new interface, old implementation) - при реализации изменений мы можем определить новый красивый интерфейс и всех перевести на него, а поначалу под капотом дергать вызов старой реализации. На самом деле это дефолтный подход при миграциях:)
- Порядок чтения кода (reading order) - файл с кодом должен быть устроен так, чтобы его было удобно изучать читателю (забавно, что это верно для всего: книг, презентаций, мануалов)
- Принцип связности (cohesion order) - суть в том, чтобы организовать код в файле так, чтобы при изменениях элементы, что меняются вместе, распологались рядом. Это же верно и для разных файлов, что сцеплены (coupling) - их можно перенести в общий каталог.
- Соединение объявления переменной и его инициализации (move declaration and initialization together) - опять же тут суть в том, чтобы свести связанные кусочки логики вместе
- Пояснительные переменные (explaining variables) - создание отдельных переменных для сложных выражений вместо вычисления их just in place, например при прокидывании выражения в параметры вызываемой функции
- Пояснительные константы (explaining constants) - создание констант вместо раскиданных по коду магических значений
- Явная передача параметров (explicit parameters) - вместо прокидывания hashmap с ненормированным количеством параметров лучше их явно прокинуть в параметры при вызове функции
- Визуальная группировка инструкций (chunk statements) - если при чтении кода вы понимаете, что одна часть делает вот это, а другая делает то, то просто добавьте дополнительную пустую линию между этими блоками кода, плюс этот блоки кода можно улучшать при помощи остальных советов из этой части
- Извлечение функций-хелперов (extract helper) - извлечение вспомогательных блоков кода в отдельные функции с именем
- Одна большая свалка (one pile) - во время очистки иногда требуется свести все части кода в одно место, а уже потом применять остальные подходы. Когда мы делаем так, то получаем одну большую свалку.
- Содержательные комментарии (explaining comments) - если при чтении куска кода у вас щелкает и возникает мысль "Ах, вот что это такое", то есть смысл записать это озарение в комментарий
- Удаление избыточных комментариев (delete redundant comments) - иногда при очистке кода часть комментариев становится очевидной, в этот момент такие комментарии стоит удалить.

#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture

Lessons from a Hyperscaler • Casey Rosenthal • GOTO 2024

Интересный доклад от Casey Rosenthal, автора книги "Chaos Engineering", в котором он рассказывает о тех уроках, что были получены от работы в компаниях-гиперскейлерах, где hyperscale это

Hyperscale is the ability of an architecture to scale appropriately as increased demand is added to the system.

Сам автор работал в компании Netflix и был изначально в traffic team, которая отвечала за то, чтобы Netflix работал для пользователей. А в комплексных системах возникает такой уровень сложности, который не помещается ни в одну голову. Для того, чтобы бороться с этой сложностью в Netflix придумали Chaos Monkey, который рандомно отключает машинки с частями системы. Это помогает инженерам искать системные недостатки и принимать решения для повышения надежности системы. Дальше автор приводит конкретный пример с двумя микросервисами, один из которых stateful и хранит данные в persistent DB, а также у него есть кеш в Redis. А дальше что-то идет не так со stateful сервисом и вся система деградирует:) Суть примера в том, что в комплексных системах возможны пробелмы, несмотря на то, что все компоненты соответствуют спецификациям.

Автор говорит про 4 модели, что помогают гиперскейлерам бороться со сложностью:
- Observability (not metrics) - обеспечение наблюдаемости системы, просто метрик для этого не достаточно
- DevUX (platfoorm engineering) - создание платформенных команд, что делают dev2dev продукты, что снижают когнитивную сложность (можно почитать мой разбор "State of Platform Engineering Report 2023 от Puppet")
- Experimentation over testing - экспериментирование, а не тестирование. Суть в том, что эксперименты помогают узнать что-то новое о системе, а тестирование - это проверка того, что система соответствует нашим ожиданиям
- Low bureaucracy - низкий уровень бюрократии, где у инженеров достаточно полномочий на то, чтобы делать свою работу без кучи согласований

Автор рассказывает про 4 экономических столпа комлексности
- States - ограничение количества состояний системы. Например, Ford Model T, где потребитель мог купить машину любого цвета, если этот цвет черный:) Но сейчас это ушло в прошлое и мы ценим вариативность и персонализацию продуктов под конкретного клиента
- Relationships - здесь у нас тоже все идет по нарастающей - добавляются новые связи, новые уровни абстракции, динамическое поведение систем становится все сложнее
- Environment - окружающая среда тоже не отличается предсказуемостью и мало кто из компаний может на нее как-то значимо повлиять в свою пользу (если вы не Amazon или Google)
- Reversability - а вот тут разработка софта сильно выделяется на общем фоне. Мы можем выбрать для себя фокус на этом и получить возможность откатывать изменения. Тут нам в помощь CI/CD, a/b тестирование гипотез, ... Но для того, чтобы это все работало нам требуется observability.

И автор рассказывает про подходы: observability 1.0 и observability 2.0, где observability 1.0 это
• Metrics (метрики)
• Unstructured logs (неструктурированные логи)
• Structure logs (структурированные логи)
Недостатком observability 1.0 является убывающая полезность и нарастающие затраты на создание и хранение логов и метрик. Суть в том, что по мере роста системы, добавления компонентов, инцидентов, логов будет становиться все больше и сложно будет искать в них нужную информацию, а также это все будет занимать все больше места.

В качестве ответа автор говорит про observability 2.0, который обладает следующими возможностями:
- Это подход с high cardinality / high dimenions и в одном месте, который является единым источником истины
- Из этого хранилища можно получать показатели, логи, структурированные и неструктурированные данные
- А кроме того, это не уменьшает эффективность разработчиков, а скорее увеличивает за счет использования одного решения

У нас в Tinkoff таким единым источником истины является Sage, наша obserbility платформа, которая является стандартом де-факто для всех в компании.

#Devops #PlatformEngineering #Management #SoftwareDevelopment #Software #SRE

Чистый дизайн (Tidy First?) - Part III - Управление (Managing)

Продолжая посты (1 и 2) о книге "Чистый дизайн" расскажу про вторую часть, в которой автор рассказывает о том, как управлять очисткой: когда начинать, когда заканчивать, а также как объединить ее с изменением поведения системы. Здесь автор дает следующие советы

- Очистка отдельно (separate tidying) - очистку надо проводить отдельно от изменений, что меняют поведение системы. Это можно легко организовать заворачивая все изменения по очистке в отдельный MR (merge request). Плюс надо думать над размером MR - он должен давать некоторую картину для понимания изменений, но, одновременно, не быть слишком большим для осмысления
- Цепочки (chaining) - когда вы начинаете очистку, то эти изменения начинают создавать изменения для дальнейшей очистки. Важно уметь планировать очистку на несколько шагов, а также знать, когда требуется остановиться. Подробнее про подходы к очистке можно прочитать во втором посте по книге
- Размер наборов операций (batch sizes) - здесь автор рассказывает как определиться с размером очистики. Он предлагает оценивать стоимость ревью изменений (что форсирует не делать маленькие MRs с очисткой) и проблемы с большими батчами по очистке: потенциальные коллизии, изменения в поведении и спекулятивные изменения. В итоге, нам надо найти оптимум:)
- Ритм (rhythm) - автор говорит о том, что в уборке нужна ритмичность - мы не можем разово убраться и забыть об очистке:) Нам надо делать это периодически, если мы хотим жить в чистом месте
- Распутывание (getting untangled) - иногда, при написании кода, изменяющего поведение, приходит идея провести очистку. Дальше опять дописать код, что меняет поведение, а потом еще почистить код. Автор предлагает не делать так, а если все таки у вас получилось такое запутанное изменение, то снести его и дальше сделать все сначала с новыми знаниями и пониманием, что надо поделить изменения поведения и очистку на отдельные MRs
- До, после, позже, никогда (first, after, later, never) - ответ на вопрос, а когда делать очистку. И это как обычно it depends ... И тут все зависит от экономических эффектов: если очистка сильно поможет нам с дальнейшим внесением изменений, то можно начать с нее. А если нам никогда-никогда не придется менять код (мы пишем разовый скрипт), то чистить ничего не требуется:) А вот варианты в промежутке уже посложнее и по ним автор дает следующие рекомендации:
- Проводите очистку после изменений, если
-- Ожидание следующего удобного случая, чтобы провести ее сразу перед изменениями, обойдется дороже
-- Без этого вы не чувствуете, что работа завершена
- Проводите очистку позже, если
-- Очистка предполагает много работы, которая не возымеет немедленного эффекта
-- Ее завершение окупится позже
-- Ее можно проводить небольшими частями

#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture

МегаШкола ИТМО 2024 Игорь Котенков - State of the LLM Landscape

Интересный доклад с обобщением состояния дел в LLM (large language modes) от Игоря Котенкова, автора канала "Сиолошная" (@seeallochnaya), который я почитываю с интересом. Конкретно в этом видео автор за 2 часа дает хороший обзор последних достижений для студентов ИТМО.

Из презентации (что доступна здесь) я вынес следующие моменты
- Что такое большие языковые модели, как они работают и для чего их сейчас используют
- Как LLMs уже влияют на реальный мир (особенно когда они начинают использовать интернет для выполнения действий) и какое их ждет будущее
- Как обучают большие языковые модели - по-факту, модели предсказывают следующее слово в контексте, модель обучается на большом количестве текста (значимая часть интернета), дальше на выходе получается многогигабайт параметров, которые задают веса в моделе
- Дальше модельку доучивают с использованием человека - есть пара текстов, где один из ответов выбирается человеком как лучший и это подается модельке. В итоге, это ускоряет процесс обучения и оптимизирует человеческие предпочтения.
- ChatGPT - для создания модели использовались огромные мощности и высококачественные данные, а дальше продукт стал самым быстрорастущим в мире и достиг 100 млн пользователей примерно за 2 месяца
- Чатботы сейчас уже можно использовать для автоматизации деятельности, например, для повышения эффективности разработчиков (подробнее в докладе про Copilot) или для повышения эффективности консультантов (пример от BCG)
- LLMs могут научиться не просто гененрировать текст, но и некоторым навыкам, например, математическим
- Исследователи активно работают на интерпертируемостью LLMs, в перспективе это позволяет модели запоминать и применять паттерны, а не запоминать все подряд.
- При использовании LLMs могут быть проблемы с утечкой конфиденциальной информации
- Пока единственный гарантированный способ сделать LLM лучше - это насыпать больше мощностей и подкинуть данные получше на стадии обучения, но исследователи постоянно пытаются придумать еще что-то, например, оптимизируя алгоритмы
- К моделям можно подключать инструменты, например, калькулятор (или Wolfram Alfa, про это можно подробнее почитать в книге Стивена Вольфрама "What Is ChatGPT Doing ... and Why Does It Work?", про которую я рассказывал раньше)
- Модели можно помогать, попросив построить цепочку рассуждения (chain-of-thought prompting)
- Дальше внешние инструменты и chain-of-thought можно объединить в подходе ReAct (Reasoning + Actions). ReAct - это способ промтинга, позволяющий модели выполнять несколько шагов поиска информации. Игорь дает интересные примеры с моделями
-- Для поиска информации в интернете и вставкой текста в модель
-- Для использования сервиса для обмана капчи:)
-- Для синтеза ядов
-- Для генерации предметов в майнкрафте, где модель создала себе skill library и выучила скиллы по созданию предметов
- LLMs могут работать не только с текстом, но и с видео, звуками и другими модальностями
- На базе LLMs можно создавать автономные браузерные агенты, которые будут выполнять действия на сайте, предсказывая, что нужно сделать.
- Для обучения моделей можно использовать синтетические данные, сгенерированные другими моделями. Это позволяет улучшить качество обучения и увеличить навыки модели.
- Есть направление по использованию LLM в научных исследованиях, так как LLM могут генерировать десятки тысяч, сотни тысяч ответов на задачи, что позволяет строить дерево мыслей и находить правильный ответ. В будущем такие модели могут быть использованы для создания научных статей и новых знаний.
- Сейчас LLMs могут выдумывать факты или соглашаться с неправильными фактами, но это может быть решено в будущем.
- Дальше ML будет охватывать все новые и новые сферы или доводить до идеала те, в которых уже применяются технологии. В итоге, будет работа как по созданию лучших моделей, так и по интеграции существующих моделей для решения реальных бизнес-задач.

#DataScience #ML #AI #Data #PopularScience #Math

Чистый дизайн (Tidy First?) - Part IV - Теория (Theory)

Продолжая посты (1, 2 и 3) о книге "Чистый дизайн" расскажу про последнюю часть, в которой автор делится своими теоретическими изысканимями, которые позволяют наработать интуицию в принятии решений относительно дизайна софта. Здесь автор рассматривает вопросы

- Что такое программный дизайн?
- Как дизайн влияет на разработку и эксплуатацию софта и наоборот?
- Стоит ли вкладываться в проработку струтктуры софта и к чем это приведет?
- Каакие принципы (экономические и гуманитарные) можно использовать для принятия решений о изменении структуры софта?

И вот что я вынес из этой части
- Взаимовыгодные отношения между элементами (bene€cially relating elements) - собственно, это и есть определение программного дизайна от автора, которое лаконично и интересно. По-факту, в определении приведены основные части: элементы, отношения и взаимная выгода между ними. А дизайнеры - это те, кто как раз обеспечивают то, чтобы отношения были взаимовыгодными.
- Структура и поведение (structure and behavior) - ценность кода в том, что он умеет делать уже сейчас (поведение), а также в том, что он сможет делать завтра (структура). Поведение можно характеризовать двумя способами: парами вход/выход и инвариантами, которые сохраняются во время изменений системы. Структура не влияет напрямую на поведение, но она влияет на варианты развития событий - насколько нам просто будет дорабатывать систему тем или иным способом. Изменения в поведении видны сразу, а вот изменения в структуре замерить сложно, поэтому их часто откладывают.
- Экономика: ценность во времени и вариативность (economics: time value and optionality) - автор рассказывает про природу денег:
-- Доллар сегодня стоит больше доллара завтра, поэтому зарабатывать надо раньше - тут можно посмотреть в сторону дисконтированных денежных потоков и NPV
-- В ситуации хаоса лучше вариативность, чем однозначность, поэтому перед лицом неопределенность создавайте варианты
В итоге, задачей дизайн автор видит согласование императивов "зарабатывать раньше/тратить позже" (поведение) и "создаавать вариативность, а не однозначность" (структура).
- Доллар сегодня стоит больше, чем доллар завтра (a dollar today > a dollar tomorrow) - рассказ про пальцах про дисконтирование денежных потоков
- Вариативность (options) - рассказ про "дилемму Златовласки", где у нас не должно быть слишком много дизайна или очень рано, но и не должно быть слишком мало дизайна или слишком поздно. Дальше вступает в дело концепция опционов, когда мы платим деньги сейчас за возможность купить что-то в будущем. В итоге, проектирование, которым мы знимаемся сегодня, - это "опционная премия", которую мы платим, "покупая" изменения поведения программы в будущем.
- Опционы и денежные потоки (options versus cash flows) - здесь автор объясняет как принимать решения об очистке (tidying) с учетом наших знаний ою опционах. Одновременно звучит тезис о том, что программный дизайн - это про налаживание отношений с людьми, а очистка - это про отношения с самим собой:) Считать всю экономику для очистки часто бывает затратно, но принимая решения о ней мы тренируем
-- Привычку читывать факторы, влияющие на время и область действия дизайна
-- Навыки выстраивать взаимоотношения с людьми
- Обратимые изменения структуры (reversible structure changes) - структурные изменения обычно обратимы, а вот изменения в поведении приводят к сайд-эффектам, которые мы не всегда можем откатить (условно, рассылка не тех сообщений не тем людям). В итоге, надо работать с разной степенью тщательности с обратимыми и необратимыми изменениями (это сходно с концепцией one-way door и two-way door decisions как это описывал Джефф Безос)

В следующем посте я расскажу про оставшиеся части теории и про литературу, что советует изучать автор.

#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture

Как Китай теряет свое экономическое превосходство | Разбор на цифрах (видео с канала MyGap)

Как-то раньше я уже говорил, что мне нравится инфографика для представления информации. А еще я люблю иногда читать комиксы по сложным темам. Обе эти вещи скомбинированы на канале MyGap, где автор делает информативные мультики на интересные темы. Например, в последнем видео была разобрана история с китайским экономическим чудом, которое вывело экономику КНР на второе место о номинальному ВВП после США, и на первое по ВВП по паритету покупательной способности (с 2014 года). Бурный рост проходил с 1979 года по 2010, но потом чуддо забуксовало и за фасадом мегапроектов забрезжили убытки и долги.

В этом видео MyGap расскажет на пальцах как китайское экономическое чудо теряет волшебный ореол и как это может отразиться на остальном мире:)

#PopularScience #Economics #Comics #Infographics