[2/3] Надежность и безопасность — это дополнительные опции или фундамент для современных ИТ-систем? (Рубрика #Architecture)

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

Ну и начнем мы с того, что у нас внутри компании есть developer ecosystem, которая представлена PaaS платформой Spirit, которая состоит из большого количества составляющих. Но начать надо с принципов, которым ребята следуют при создании платформы

— Повторяемость и прозрачность жизненного цикла кода в рамках процессов поставки. Код проходит одни и те же стадии: написание, сборка, разные формы тестирования, обновление документации, выкатка в среды, контроль качества после выкатки, поддержка и вывод из эксплуатации. Важно, чтобы любой разработчик мог понять, что происходит и какие стадии процесса ему нужно пройти.
— Управление кодовой базой и оценка ее качества на всех этапах. Качество кодовой базы — одна из главных характеристик технического продукта. Умение держать его на стабильно высоком уровне — показатель устойчивости и зрелости процессов разработки.
— Переход к Inner Source в компании. Переиспользование кода и наработок коллег — большой плюс для компании. Это помогает уменьшить стоимость разработки и увеличить скорость поставки бизнес-фич. Платформа должна помогать шерить код быстро и безболезненно.
— Ориентация на результат. Когда у разработчика есть все необходимые инструменты для управления жизненным циклом продукта, это экономит массу времени. Становится проще создавать новые фичи и чинить старые, запускать тесты и многое другое. Мы хотим, чтобы разработчики могли тратить на создание бизнес-фич 80% рабочего времени, не отвлекаясь на рутину и сложности инфраструктуры. В конечном итоге от этого выигрывают пользователи.

Составляющие платформы представлены на схеме, но если отмечать некоторые особо важные для надежности и безопасности, то это
- Sage - observability платформа, использующаяся для централизованного сбора и анализа телеметрии всех сервисов компании. Sage обеспечивает прозрачность бизнес-приложений и ИТ-инфраструктуры и помогает поддерживать бесперебойность работы сервисов.
- FineDog - платформа инцидент-менеджмента, которая помогает Т-Банку оперативно выявлять сбои в работе сервисов, сокращать время их устранения и предотвращать повторение одинаковых инцидентов.
- Nestor - copilot для code suggest и чата внутри IDE, а также других инструментов около кода и не только.
- Safeliner - это AI-ассистент по информационнои‌ безопасности для команд разработки, который может работать как внутри шагов CI/CD, так и быть интегрирован в IDE в качестве плагина.
Одновремено, надо отметить, что ребята из Spirit активно работают над темой developer experience и они про это рассказывали в докладе "Почему DevEx важен при разработке IDP и как его померить" (я про него рассказывал). Это позволяет им собирать метрики инженерного опыта и определять, а что внутри платформы требует улучшений.

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

Для изменений надо
- На уровне стратегии компании сделать эти вопросы приоритетными, определиться с понятными целями (и поставить их в OKR), согласовать выделение ресурсов
- На уровне культуры компании сделать так, чтобы security & reliability стали общей ответственностью команд
- На уровне архитектуры и проектирования учитывать эти архитектурные характеристики и использовать лучшие практики
- На уровне процессов они должны быть интегрированы в pipelines (devsecops и shift left)

Ну и все этим надо управлять как большим проектом изменений, используя change mgmt подходы

#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering

Критическое мышление. Железная логика на все случаи жизни (Рубрика #Thinking)

Эта книга Никиты Непряхина и Тараса Пащенко, позиционируется как практическое руководство для подростков, стремящихся развить навыки мышления. Моя жена купила его для детишек, а я решил прочитать и оценить как детей учат анализировать информацию, отличать факты от мнений, противостоять манипуляциям и принимать обоснованные решения. Изложение очень доступное, используются примеры из повседневной жизни. В книге рассматриваются следующие темы
1. Распознавание стереотипов и когнитивных искажений. На примерах из школьной жизни объясняется, как социальные шаблоны влияют на восприятие реальности.
2. Механизмы формирования суеверий и мифов. Разбираются психологические причины веры в иррациональное, включая эффект подтверждения и склонность к упрощённым объяснениям.
3. Влияние общественного мнения на принятие решений. Анализируются случаи конформизма и группового мышления, актуальные для подростковой среды.
4. Разграничение фактов и оценочных суждений. Приводятся критерии верификации информации, такие как проверка источников и поиск доказательств.
5. Логические основы аргументации. Обсуждаются структура умозаключений, типы аргументов и распространённые логические ошибки.
6. Практика принятия решений. Предлагаются алгоритмы взвешенного выбора в условиях неопределённости, включая анализ рисков и последствий.

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

Практическую направленность книги подтверждает то, что каждая глава содержит
- Кейсы для анализа. Читателям предлагается оценить ситуации, подобные тем, с которыми они сталкиваются в школе или соцсетях.
- Упражнения-тренажёры. Например, задание на классификацию суждений («факт vs мнение») или построение логических цепочек.
- Чек-листы и алгоритмы. Готовые схемы для проверки информации, принятия решений и аргументации.

Итого, эта книга может стать хорошей стартовой точкой для развития критического мышления для читателей старше 12 лет (возвраст указан в книге). Она особенно полезна в образовательном контексте — для уроков по логике, факультативов или семейного чтения. Для углублённого изучения темы стоит дополнить её академическими источниками, но в качестве практического руководства она выполняет свою задачу на отлично.

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

#Thinking #CriticalThinking #Reasoning #Philosophy #SelfDevelopment #Brain #Management #Leadership

AI и Platform Engineering (Рубрика #AI)

Интересное выступление Игоря Маслова, VP of Coretech & Data в Т-Банке, на открытии конференции Platform Engineering Night, про которую я уже рассказывал. Игорь открывал конференцию и рассказал о том, как AI влияет на работу инженеров и развитие инженерных платформ. Основные мысли выступления примерно следующие

1. AI как усилитель существующих платформ
Сейчас нужно "обмазывать" существующие инженерные сценарии AI - от создания пайплайнов до анализа телеметрии. В этом разрезе интересно глянуть whitepaper Google "Measuring Developer Goals", чтобы посмоттреть какие основные сценарии выделяет Google (я рассказывал о нем раньше), а также девятый выпуск "Research Insights Made Simple", в котором мы с коллегой Колей Бушковым разбирали whitepaper "What Do Developers Want From AI?" от ребят из Google
2. Когнитивная нагрузка и потеря навыков
Игорь отмечает, что активное использование AI приводит к потере низкоуровневых навыков, но считает это нормальной эволюцией - условно, мало кто пишет на ассемблере и большая часть инженеров его уже не понимает и это никого не смущает. Примерно также мы будем писать код с ассистентами на условной Java и часть людей без ассистентов его уже не смогут написать/прочитать:)
3. Режим "копайлота" как базовый уровень
Ответственность за финальный результат остаётся за человеком, что минимизирует риски "галлюцинаций" AI-моделей. Anthropic реализует эту философию в Claude, где модель действует как ассистент, а не замена разработчика. Такой подход особенно важен в критически важных системах, таких как финансы или здравоохранение, где ошибки AI недопустимы
4. Будущее: AI как платформенная инженерия
В долгосрочной перспективе AI может стать основным интерфейсом для управления инженерными процессами, устраняя необходимость в традиционных инструментах. Это направление напоминает эволюцию Kubernetes, который стал стандартом для оркестрации контейнеров, но для AI аналогичный "момент" ещё не наступил
5. Vibe Coding и персонализированный софт
Генерация кода под конкретные бизнес-кейсы или индивидуальные потребности пользователей — ключевой тренд. Однако, как предупреждает Игорь, подобные системы требуют тщательной валидации, чтобы избежать проблем с поддерживаемостью кода
6. Разгрузка разработчиков от рутины
80% экспериментальной работы можно автоматизировать, освободив время для более важных задач. OpenAI's Code Interpreter позволяет итеративно решать сложные задачи программирования и анализа данных.
7. ML-платформы: гибкость и готовность к изменениям
Инвестиции в ML-платформы оправданы, но требуют готовности к технологическим сдвигам. Например, переход от традиционных нейросетей к трансформерам в 2020-х потребовал полного пересмотра инфраструктуры у большого количества компаний. Спикер подчёркивает, что платформы должны сохранять модульность, чтобы адаптироваться к новым алгоритмам и аппаратным решениям
8. Отсутствие "момента Kubernetes" в AI
Пока нет универсального стандарта для AI-платформ, и стоит дождаться его появления. Каждая компания развивает свои подходы: OpenAI с Agents SDK, Anthropic с фокусом на безопасность, Google с комплексными AI решениями.
9. Высокорискованная природа current AI R&D
Современные AI-решения требуют больших ресурсов и подходят в основном крупным компаниям. Это подтверждается масштабными инвестициями OpenAI, Google и Microsoft в платформенные решения.
10. Постепенный подход к внедрению
Рекомендация: начинать с улучшения инструментов, но пока воздержаться от сложных low-code процессов. Anthropic следует схожей философии, предоставляя мощные модели с акцентом на контролируемое внедрение.

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

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx