Корпоративный мессенджер Time

Около полугода назад я уже рассказывал про наш корпоративный мессенджер Time, на который мы оперативно переехали, когда Slack отказался работать с русскими компаниями. За эти пару лет само решение прошло испытание огнем, водой и медными трубами и показало то, что этот мессенджер можно использовать для общения в компании с десятками тысяч сотрудников. Также поверх него можно строить бизнес-процессы и автоматизации (аля chat-ops). Какое-то время назад мы начали продавать это решение разным заказчикам сначала в on-prem варианте, а за последние полгода добавился SaaS вариант, а также mvp для видео-конференц связи. С учетом такого большого количества изменений коллеги решили провести вебинар с продактом и парой клиентов (Атом и Юрент), чтобы рассказать про плюсы и минусы продукта, а также поделится опытом переезда в Time и тем, как они выбирали из доступных на рынке решений.

В общем, если для вас актуален выбор, то регистрируйтесь на этот вебинар и дальше не стесняйтесь задавать вопросы.

P.S.
Кстати, сайт сильно обновился и стал содержать больше полезной информации навроде базового описания стека решений и интеграций
- Time - это cloud-native решение, которое у нас развернуто в наших целевых runtime окружениях (kubernetes кластерах)
- TIme можно развернуть в геораспределенном режиме (у нас, например, он развернут на 2 геораспределенных дата центра)
- Под капотом используются стандартные стек: Postgres, Kafka, Redis, Open search / Elastic search
- Есть разные виды авторизаций (SAML, AD/LDAP, openID)
- Есть возможность мигрировать с других мессенджеров (Slack, MM, RocketChat)

А также есть чиселки для технарей про один из наших инстансов Time
- 45 тысяч пользователей на инстансе в день
- 2 миллиона cообщений в день
- 80 тыс пользователей
- 5,4 миллиона диалогов создали пользователи
- 186 тысяч каналов создано этими пользователями
- более 1200 ботов создано пользователями благодаря удобной документации
- 99,9% - SLA на доступность

#Software

Архитектурные материалы для изучения от облачных провайдеров (Рубрика #Architecture)

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

1) У AWS это называется AWS Well-Architected Framework, у него 6 ключевых столпов
- Operational excellence (операционная эффективность): Фокус на управлении и мониторинге систем для обеспечения бизнес-ценности и постоянного улучшения процессов.
- Security (безопасность): Защита информации и систем с помощью надежного управления идентификацией, защиты данных и обнаружения инцидентов.
- Reliability (надежность): Обеспечение того, что рабочие нагрузки выполняются в соответствии с ожиданиями и быстро восстанавливаются после сбоев.
- Performance efficiency (эффективность): Оптимальное использование ресурсов для удовлетворения требований системы.
- Cost optimization (оптимизация затрат): Помощь в отсутствии ненужных расходов при сохранении производительности.
- Sustainability (устойчивость): Фокус на минимизации воздействия на окружающую среду за счет оптимизации энергопотребления.

2) У Microsoft это называется Azure Well-Architected Framework. Он имеет схожие цели и структуру с AWS фреймворком, в нем даже то же самое название, но столпов всего 5 (выпала часть про sustainability)
- Cost optimization (оптимизация затрат): Максимизация ценности при минимизации расходов.
- Operational excellence (операционная эффективность): Эффективное управление операциями и автоматизация процессов.
- Performance efficiency (эффективность): Обеспечение производительности и масштабируемости приложений.
- Reliability (надежность): Построение отказоустойчивых архитектур, способных восстанавливаться после сбоев.
- Security (безопасность): Защита данных и систем через надежные методы безопасности.

3) У Google это называется Cloud Architecture Framework. Он имеет немного другую структуру, но также фокусируется на ключевых принципах построения облачных решений. У него пять столпов:
- Operational excellence (операционная эффективность): Эффективное развертывание, эксплуатация, мониторинг и управление рабочими нагрузками.
- Security, privacy, and compliance (Безопасность, конфиденциальность и соответствие требованиям): Обеспечение безопасности данных, их конфиденциальности и соблюдения нормативных требований.
- Reliability (надежность): Построение отказоустойчивых систем, способных выдерживать сбои.
- Cost optimization (оптимизация затрат): Максимизация бизнес-ценности за счет оптимизации использования ресурсов.
- Performance optimization (оптимизация производительности): Настройка ресурсов для достижения оптимальной производительности.

Из этого краткого описания фреймворков видно, что у них похожие фокусы на оптимизацию затрат, безопасность, оптимизацию производительности, надежность. В общем, на вопросы, которые важны для клиентов, что планируют заезжать в облака (но важны также и при разворачивании on-prem). Эти фреймворки направлены на то, чтобы помочь организациям постоянно оценивать и улучшать свои облачные архитектуры на основе лучших практик, предоставляемых соответствующими облачными провайдерами. Хотя конкретные детали реализации могут различаться между провайдерами, основные принципы остаются схожими на всех платформах.

Кстати, часть научных статей ребят превращаются в мануалы внутри этих фреймворков. Например, раздел "Deployment archetypes" из документации Google изложен в научной статье "Deployment Archetypes for Cloud Applications", которую я разбирал больше года назад в своем блоге.

#DistributedSystems #ExternalReview #SoftwareDevelopment #SoftwareArchitecture #Architecture #SystemDesign #SystemEngineering #Cloud

Ководство (Рубрика #Design)

Недавно я прочитал седьмое издание книги Артемия Лебедева, которое доступно на его сайте онлайн под названием ".ру/Ководство". Если кратко, то кажется в далеком детстве Рунета Артемий Лебедев был достаточно интересен как в плане дизайна, так и текстов. Условно, если бы я читал его мысли в начале двухтысячных, когда только начинал свой путь в софтостроении, то это было бы полезно. Сейчас же эти статьи читаются скорее как байки о старых временах от интересного человека из той эпохи ... они пахнут нафталином как в детстве, когда шубу или пальто доставали из шкафа с зимней одеждой. В общем, почитать книгу можно ради воспоминаний ... и интересных мыслей про типографику. Кстати, книгу покупать не обязательно - их можно почитать и на сайте автора.

P.S.
Мне книга скорее понравилась, но допускаю, что это из-за того, что я помню как все начиналось ... в рунете:)

#Design #Visualization

What Is This OpenTelemetry Thing? • Martin Thwaites • GOTO 2024 (Рубрика #Architecture)

Интересное выступление на goto конференции от Martin Thwaites, Principal Developer Advocate из Honeycomb. Основная суть выступления примерно такая
1) Автор начинает с истоков наблюдаемости, когда люди ориентировались еще на мигающие лампочки на самих устройствах:)
2) В 2000х годах использовались метрики для мониторинга производственных систем, так как места было мало и производительность систем была не слишком большой. Тут важно было правильно предагрегировать данные, изначально понимая какая информация будет нужна, так как метрики расчитывались заранее, а оригинальные события не хранились. Где-то в 2010х годах для хранения метрик стали использовать time-series базы данных
3) Дальше стали популярны логи, для которых зачастую использовался ELK стек (Elastic, Logstach, Kibana). Это позволило уйти от предварительной агрегации данных и улучшить наблюдаемость. По-факту, в Kibana можно было пост-фактум строить красивые дашборды, агрегируя данные так, как необходимо
4) Где-то с середины 2010х годов системы стали сложнее и распределеннее и дальше появились инструменты для распределенной трассировки и стандарты OpenTracing и OpenCensus
5) В какой-то момент они объединились и превратились в OpenTelemetry - это проект CNCF в статусе incubating, что наряду с graduated считается стабильным и пригодным для использования в проде
6) OpenTelemetry хорош тем, что он пришел на смену двум предыдущим стандартам, что со временем стали deprecated и позволил отвязать инструментализацию телеметрии от бекендов, в которые она отправляется. У этого стандарта есть протокол и SDK для всех популярных языков программирования
7) У OpenTelemetry есть и проблемы - он развивается через комитеты, что замедляет процесс доработок и расширений стандарта
😍 В OpenTelemetry есть логи, метрики, трейсы. Трейсы - это способ для описания взаимодействия сервисов с учетом причинно-следственных связей (это делается через связи между спанами). Вообще, трейсы позволяют очень удобно разбираться с поведением сложной распределенной системы.
9) Логи предназначены для людей и имеют шаблон сообщения, они полезны для локальной отладки и проверки работы трассировок
10) Метрики - это агрегированные временные ряды данных. Они используются для измерения и анализа производительности. Дешевы в хранении и быстры в обработке, но ограничены в контексте и размерности.
11) OpenTelemetry позволяет думать о соединениях между системами. Распространение данных включает корреляцию и передачу информации о состоянии. Спецификация контекста трассировки W3C определяет заголовки и данные для передачи.
12) Автор подробно говорит про W3C Baggage, propagation format for distributed context. Он как раз позволяет передавать дополнительный контекст между службами, но есть там и проблемки, например, передача данных через сторонние API может привести к утечке конфиденциальной информации.
13) Круто, когда инструментализация OpenTelemetry встроена в шаблоны ваших приложений - это помогает командам SRE получать стандартизированные observability данные
14) У OpenTelemetry есть collector, который используется для проксирования и обработки данных телеметрии. Он позволяет централизовать конфигурацию и отправку данных нескольким поставщикам, а также обеспечить центральную точку для инфобезов или обогощения данных
15) В OpenTelemetry можно настраивать семплинг для уменьшения затрат на наблюдаемость
16) Прикольно семплировать не с головы, а с хвоста, когда мы знаем что попало в трейсинг. Хвостовой сэмплер может сообщать о медленных процессах и ошибках, но компромисс здесь в том, что задержка отправки данных и большие затраты памяти.
17) У OpenTelemetry есть и проблемки - отправка данных через перекрестные зоны доступности может быть дорогой. Решения по отправке данных требуют компромиссов. OpenTelemetry требует постоянного внимания и настройки.
18) В будещем в OpenTelemetry ожидается больше семантических соглашений и библиотек

#SRE #Architecture #DistributedSystems #Software

Research Insights Made Simple #4 - Обсуждение "AI-Enhanced API Design"

В этом эпизоде мы обсуждаем интересный whitepaper "AI-Enhanced API Design" от ребят из Google, где рассказывалось о том, как подходы к управлению API влияют на продуктивность и usability. Исследователи показали, что общие стандарты вместе с инструментами, которые помогают им следовать, приводят к статистически значимым улучшениям в качестве дизайна API.

В разборе мне помогает крутой гость - Павел Каравашкин, мой коллега. Павел является руководителем разработки платформы T-API, а также лидером профессии системного анализа в Т-Бизнес, соведущим подкаста SA Т-Банка InSAйт. Паша любит велоспорт, Warhammer 40k и читать случайные статьи на Википедии.

Кстати, эпизод доступен и в подкасте Яндекс Музыки.

Материалы:
- AI-Enhanced API Design: A New Paradigm in Usability and Efficiency
- Мой обзор этой научной статьи
- Публичное T-API для партнеров
- Подкаст InSAйт

Мы обсудили следующие моменты
- Обзор статьи и личные впечатления Павла
- Обсуждение структуры статьи
- Проблемы и аспекты проектирования API
- Процесс разработки API в Google
- Гибкость и стандартизация в разработке API
- Методология исследований в Google
- Подходы к исследованием вокруг API в T-банке
- Проблемы и решения в персонализации
- Использование линтеров и метрик
- Анализ логов и задач разработчиков
- Исследования и метрики в Google
- Генерация контрактов
- Проблемы с архитекторами
- Методология эксперимента в Google и его результаты
- Ограничения эксперимента
- В общем про процесс разработки и помощь автоматизированных средств
- Важность этапа реализации
- Архитектура и улучшение процессов
- Измерение эффективности инструментария (отсылка к статье "Measuring developer goals" от ребят из Google)
- Роли в разработке
- Автоматизация кибербезопасности (отсылка к предыдущему подкасту)Заключение и планы на будущее

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

Интересная информация от канала "эйай ньюз", за которым я слежу, чтобы не отставать от новостей AI.
Здесь интересна информация о том, а как крупные компании используют AI в своих процессах и оказалось, что все просто
1) Customer support/service - тут всеми "любимые" чатботы и не только
2) Marketing/content generation - генерация маркетингового контента, рекомендаций продуктов (eBay)
3) Document processing / infromation retrieval - обработка документов, суммаризация встреч, поиск по данным
4) Development/code generation - генерация кода (Gitlab, Autodesk), теста (Notion), ...
5) Employee/internal tools - внутренние инструменты для сотрудников

В принципе, список неполный, но достаточно полезный. У нас, например, по всем из этих направлений тоже ведется работа.

T=Математика (#PopularScience)

1 декабря будет день математики и мои коллеги из Т-Образования устраивают большой праздник с кучей активностей: лекции, математические игры, интенсив по финграмотности и многое другое
- 11 — 24 ноября - Интенсив по олимпиадным задачам (онлайн) - подготовка к муниципальному этапу ВсОШ (разборы от опытных преподавателей, тренировки в решении задач
- 16 ноября - Интенсив по финграмотности (оффлайн и онлайн) - мероприятие пройдет в T-Space (Москва, м. Белорусская), в программе будет несколько докладов
- 28-30 ноября - Турнир по математическим играм (онлайн) - на турнире будут командные игры: «Математический квадрат», «Математическая карусель» и «Семь чудес». Победители получат памятные призы от Т-Образования
- 1 декабря в T-Space в Москве - День математика (оффлайн) - мероприятие пройдет в T-Space (Москва, м. Белорусская), в программе будут лекции, нетворкинг и фуршет.

#PopularScience #Math

0b1000 в Т-Банке

Сегодня у меня юбилей в Т-Банке, 8 лет:) Именно столько лет назад я пришел в тогда еще Тинькофф. Я пришел из Банки.ру, где был лидом команды разработки, что отвечала за рейтинги банков, страховых и остальной UGC (user generated content), а также лидогенерящие странички:) В Тинькофф я вышел на позицию engineering manager заниматься проектами привлечения. Планы на старте были наполеоновскими и они действительно драйвили меня. Это был период роста и моя зона ответственности постоянно менялась. Я чувствовал себя не просто engineering менеджером, а скорее менеджером непрерывных изменений с девизом "пересобери себя и свою команду или умри"... Но как только я справлялся с новым вызовом, то получал следующий. Это происходило примерно каждые полтора-два года. Про многие из этих изменений я рассказывал на YaTalks в прошлом году и в расшифровке этого выступления. С тех пор я собрал у себя dream team из руководителей, которые отвечают за отдельные большие подразделения в 200-300 человек
- Клиентские интерфейсы: платформенные команды веба, мобилы и API
- Маркетинговые технологии: внешняя реклама, маркетинговая платформа
- Соц-медиа платформы: социальные сети, медиаплатформа, медиапроекты (ТЖ, Бизнес-секреты), игры
- Цифровые экосистемы: аутентификация/авторизация, биометрия, главная страница приложения, финздоровье

А еще у меня в подразделении есть важный для меня продукт в виде продуктовой аналитика и a/b платформы. Это важно для компании для того, чтобы быть data-driven, а для меня - это возможность закрыть гештальт относительно математики (теорвер, матстатистика), которая мне нравилась всю дорогу от лицея до физтеха и дальше:) Также я отвечаю за архитектуру как функцию в компании. Это мне близко как технарю, для которого важна engineering excellence и design крутых систем.

Напоследок, я хотел сказать спасибо ребятам из моего юнита "Клиентские интерфейсы, маркетинг и вовлечение". Ребята и делают всю работу, которая приносит радость нашим клиентам, деньги компании, а мне позволяет рассказывать об этом. Кстати, с частью ребят я записывал интервью
- Про архитектуру с моим замом, Антоном Костериным. Антон руководит архитектурной группой при мне
- Про про системных аналитиков с Кириллом Крайневым. Кирилл руководит маркетинговыми технологиями, а также драйвит развитие профессии системных аналитиков
- Про Staff+ инженеров, архитектуру и SDLC с Алексеем Тарасовым. Алексей руководит соц-медиа платформой, а также драйвит наши system design interview и помогает развивать направление staff+ для инженеров
- Про систему для продуктовой аналитики (Statist) с Андреем Цыбиным. Андрей руководит продуктовой аналитикой и a/b платформой.

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

P.S.
В общем, 8 лет - это большой срок, который можно и отметить. Особенно с учетом того, что я не уверен в том, что "доживу" до следующего круглого юбилея в двоичной системе:)

#Management #SelfDevelopment #Engineering #Processes #Software

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

#SelfDevelopment

#psy
Мы с группой коллег проводим исследование, посвященное
формированию и развитию новой профессиональной идентичности.
Для практической части мы выбрали профессии, связанные с управлением продуктом.
Если вы недавно перешли в такую профессию, находитесь в процессе перехода или планируете его, приглашаю принять участие в нашей психаналитической группе "Как занять свое место в профессии".

Примеры вопросов, которые могут возникать:
- Вокруг все говорят, что ты product manager, а сам ты про себя так не говоришь/не можешь сказать кто ты;
- Хочешь стать product manager, но не дают\не получается (по разным причинам);
- Уже работаешь в управлении продуктом, но не можешь понять, кто ты такой в своей текущей роли на работе

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

Состав группы - 12-15 человек
Длительность встречи - 2 часа
Встречи будут онлайн по субботам, 6 встреч, 1 раз в неделю.

Перед стартом группы будет проведена индивидуальная встреча с одним из консультантов (1 час) для знакомства с методом и друг с другом.

Вся информация строго конфиденциальна и будет обезличена в рамках исследования.

Если вам интересно, пишите в лс

Менторинг сессия на канале SouthHub (Рубрика #Management)

Во вторник вечером я проводил менторинг сессию, запись которой доступна на Youtube. Моим менти был Антон Числов, технический директор МТС Авто. Запрос был на меторинг по теме как осуществлять крупные изменения в больших компаниях. Суть в том, что у ребят на носу 2 больших изменения
1) Переход от разработки по компонентам к stream-aligned командам
2) Переезд из MTS Digital в отдельную компанию внутри экосистемы

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

#Management #Leadership #Processes #Software

Законы простоты (The Laws of Simplicity) (Рубрика #Design)

На днях я прочитал книгу Джона Маэды о законах простоты. Сам Джон является выдающимся американским дизайнером, ученым и педагогом, который известный своими работами на стыке бизнеса, дизайна и технологий. Сейчас он работает вице-президентом по дизайну и искусственному интеллекту в Microsoft. Интересно, что это уже вторая книга этого автора, которая мне понравилась, первой была "ReDesisning Leadership" ("Редизайн лидерства"), о которой я уже писал в канале. Если же возвращаться к самой книге о законах простоты, то интересно, что он написал ее почти 20 лет назад, еще до выхода айфонов на рынок. Тогда она стала бестселлером, но дизайнеры с тех пор двигаются скорее в сторону сложности:)

Джон предложил использовать следующий список законов для нахождения баланса между сложностью и простотой в различных аспектах жизни и работы, делая системы более интуитивными и эффективными
1. Сокращение (Reduce) — Самый простой способ достичь простоты — это осознанное сокращение. Убирайте лишнее, но будьте осторожны, чтобы не убрать что-то важное.
2. Организация (Organize) — Организация помогает сделать систему с множеством элементов более понятной и управляемой. Правильная структура делает сложное проще.
3. Время (Time) — Экономия времени создает ощущение простоты. Чем меньше времени требуется на выполнение задачи, тем проще она воспринимается.
4. Обучение (Learn) — Знания упрощают все. Чем больше вы знаете о системе или процессе, тем легче с ними работать.
5. Различия (Differences) — Простота и сложность взаимосвязаны. Чтобы оценить простоту, необходимо иметь возможность сравнивать ее с чем-то более сложным.
6. Контекст (Context) — То, что находится на периферии простоты, не является незначительным. Контекст важен для понимания и восприятия системы.
7. Эмоции (Emotion) — Больше эмоций лучше, чем меньше. Эмоциональная связь с продуктом или системой делает их более привлекательными и понятными.
8. Доверие (Trust) — Простота требует доверия. Пользователи должны доверять системе, чтобы она казалась простой в использовании.
9. Неудача (Failure) — Некоторые вещи невозможно упростить. Не все попытки создать простоту будут успешными, но важно учиться на ошибках.
10. Единое (The One) — Простота заключается в вычитании очевидного и добавлении значимого. Это объединяющий принцип всех предыдущих законов.

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

#Design #Leadership #Management #SelfDevelopment #Processes