اکنون در دسترس! پژوهش تلگرام ۲۰۲۵ — مهمترین بینشهای سال 
Russian Association of Software Architects
رفتن به کانال در Telegram
Канал самоуправляется коллегией: @sergey486 и @emacsway . Бот для вступления в авторский коллектив: @ru_arc_bot Предложить доклад для митапа: @ru_arc_meetup_bot Группы: @ru_arc_chat @rasa_business @archicases Рекламу не размещаем.
نمایش بیشتر4 319
مشترکین
اطلاعاتی وجود ندارد24 ساعت
اطلاعاتی وجود ندارد7 روز
-1830 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
ژوئن '26
ژوئن '26
+7
در 0 کانالها
مه '26
+30
در 0 کانالها
Get PRO
آوریل '26
+32
در 0 کانالها
Get PRO
مارس '26
+50
در 1 کانالها
Get PRO
فوریه '26
+34
در 0 کانالها
Get PRO
ژانویه '26
+50
در 2 کانالها
Get PRO
دسامبر '25
+45
در 1 کانالها
Get PRO
نوامبر '25
+77
در 1 کانالها
Get PRO
اکتبر '25
+52
در 1 کانالها
Get PRO
سپتامبر '25
+65
در 1 کانالها
Get PRO
اوت '25
+139
در 2 کانالها
Get PRO
ژوئیه '25
+92
در 1 کانالها
Get PRO
ژوئن '25
+36
در 1 کانالها
Get PRO
مه '25
+59
در 1 کانالها
Get PRO
آوریل '25
+52
در 0 کانالها
Get PRO
مارس '25
+100
در 0 کانالها
Get PRO
فوریه '25
+75
در 1 کانالها
Get PRO
ژانویه '25
+63
در 0 کانالها
Get PRO
دسامبر '24
+98
در 3 کانالها
Get PRO
نوامبر '24
+110
در 1 کانالها
Get PRO
اکتبر '24
+176
در 1 کانالها
Get PRO
سپتامبر '24
+103
در 0 کانالها
Get PRO
اوت '24
+113
در 3 کانالها
Get PRO
ژوئیه '24
+79
در 2 کانالها
Get PRO
ژوئن '24
+89
در 1 کانالها
Get PRO
مه '24
+133
در 3 کانالها
Get PRO
آوریل '24
+74
در 0 کانالها
Get PRO
مارس '24
+80
در 0 کانالها
Get PRO
فوریه '24
+113
در 3 کانالها
Get PRO
ژانویه '24
+177
در 3 کانالها
Get PRO
دسامبر '23
+234
در 4 کانالها
Get PRO
نوامبر '23
+126
در 5 کانالها
Get PRO
اکتبر '23
+182
در 3 کانالها
Get PRO
سپتامبر '23
+86
در 0 کانالها
Get PRO
اوت '23
+83
در 0 کانالها
Get PRO
ژوئیه '23
+86
در 0 کانالها
Get PRO
ژوئن '23
+44
در 0 کانالها
Get PRO
مه '23
+105
در 0 کانالها
Get PRO
آوریل '23
+75
در 0 کانالها
Get PRO
مارس '23
+60
در 0 کانالها
Get PRO
فوریه '23
+127
در 0 کانالها
Get PRO
ژانویه '23
+76
در 0 کانالها
Get PRO
دسامبر '22
+72
در 0 کانالها
Get PRO
نوامبر '22
+149
در 0 کانالها
Get PRO
اکتبر '22
+213
در 0 کانالها
Get PRO
سپتامبر '22
+255
در 0 کانالها
Get PRO
اوت '22
+185
در 0 کانالها
Get PRO
ژوئیه '22
+1 186
در 0 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 12 ژوئن | +1 | |||
| 11 ژوئن | +1 | |||
| 10 ژوئن | 0 | |||
| 09 ژوئن | +3 | |||
| 08 ژوئن | 0 | |||
| 07 ژوئن | 0 | |||
| 06 ژوئن | 0 | |||
| 05 ژوئن | 0 | |||
| 04 ژوئن | 0 | |||
| 03 ژوئن | +1 | |||
| 02 ژوئن | +1 | |||
| 01 ژوئن | 0 |
پستهای کانال
Repost from N/a
Structured-Prompt-Driven Development (SPDD)
LLM programming assistants have demonstrated considerable value, but mostly with individual developers. The internal IT organization in Thoughtworks has been using them for their teams and have developed a method and workflow called Structured Prompt-Driven Development (SPDD). Wei Zhang and Jessie Jie Xia describe a simple example of this workflow with details in github. This workflow treats the prompts as a first-class artifact, kept with the code in version control, and used to align development with business needs. They have found that developers need three key skills to be effective: alignment, abstraction-first, and iterative review.
more…
via Martin Fowler
| 2 |  401 meetup – call for papers
Друзья, пишу поделиться отличной новостью!
Анонсирую оффлайн-митап про Identity & Access Management (IAM) в Москве 27 мая. Концепция: свободный вендор-независимый митап для сообщества.
Подробности и начало регистрации для участников будут объявлены позднее, а пока приглашаю спикеров заявиться с докладами.
Очень жду и приветствую доклады про аутентификацию, управление доступом и смежные области. Это будет классная возможность выступить на релевантную аудиторию.
Тайминг 35-40 минут. Запись постараюсь организовать, чтобы материалы были доступны.
Принимаем любые идеи, крутые технические или архитектурные доклады всегда в цене. А если вам нужно вдохновение, вот темы, о которых особенно хочется послушать:
- Аутентификация и авторизация: MFA, passwordless, адаптивная risk-based аутентификация, Just-in-Time Access, политики и модели контроля доступа
- Протоколы и стандарты: интересные, новаторские практики использования OAuth 2.0, OIDC, SAML, применение новых RFC и спецификаций
- Безопасность identity: Identity Threat Detection and Response (ITDR), уязвимости, атаки на аутентификацию, контроль доступа и меры защиты от них
- Практика и highload: опыт использования “нестандартного” Open Source (Ory, Casdoor, ZITADEL, etc.), адаптация IAM под высокие нагрузки и специфичные НФТ, разработка собственных IAM-решений
- Новые вызовы: аутентификация и контроль доступа для AI-агентов и MCP
- Enterprise-задачи: B2B IAM, федерации, мультитенантность
- Customer IAM (CIAM): UX и безопасность, управление аккаунтами и согласиями, social login
- Архитектура: аутентификация и контроль доступа в распределенных системах, service-to-service взаимодействия, SPIFFE
- Интеграции: комплексные решения из нескольких компонентов: IdM, IAM, SIEM, API Gateway, etc.
⛔️ Для подачи заявки на доклад заполняйте форму.
Прием заявок открыт до 1 мая (но времени не так много, не затягивайте). Со всеми заполнившими форму свяжемся.
По вопросам можно писать Андрею Кузнецову.
Сомневаетесь, подходит ли ваша тема? Оставляйте заявку – обсудим и подумаем вместе. Мы открыты к специалистам с различным опытом и профилем.
Если у вас есть идея доклада, но вы никогда не выступали и переживаете, мы поддержим и поможем подготовиться <3
Напоследок TLDR:
📆 27 мая оффлайн в Москве, площадку согласился предоставить Яндекс
📩 Заявки на доклады присылайте в форму до 1 мая
Stay tuned!
#announce #iam_general | 0 |
| 3 | Новый кейс в Архитектурных Этюдах!
«Расхождение между учетной системой и реальностью на складе»
Как построить архитектуру информационной системы управления складом, при которой физическое состояние склада и его цифровое отображение остаются синхронизированными в реальном времени несмотря на то, что операции с материалами выполняют десятки людей, не заинтересованных в корректном вводе данных?
https://t.me/c/archicases/9360 | 0 |
| 4 | Хм. Раньше настройки опроса в Телеграм по-умолчанию были такими:
• Можно выбрать только один вариант ответа
Теперь по-умолчанию через десктопное приложение осталось как и было раньше (можно выбрать только один вариант ответа), а в мобильной версии по-умолчанию теперь:
• Можно выбрать несколько вариантов
• Перемешивать варианты ответа при каждом отображении (новая настройка)
Вот я и создал опрос, через мобильное приложение, мда 🙂
Вайбкодить начали, что ли 🙂 | 0 |
| 5 | Вы бы пошли учиться IoT архитектуре? (Мотив не важен)
Говорят, огромный запрос на IoT-архитекторов, а специалистов нет, проверим интерес. | 0 |
| 6 | Новый кейс в архитектурных этюдах
«Бонусы в архитектуре процессинга»
https://t.me/archicases/8989/8990 | 0 |
| 7 | بدون متن... | 0 |
| 8 | 24-29 марта в Рабате, Марокко, проходит международная конференция в области компьютерной лингвистики EACL
Исследователи Института AIRI представляют на ней 13 работ⤵️
Основной трек
◼️SPARTA: Evaluating Reasoning Segmentation Robustness through Black-Box Adversarial Paraphrasing in Text Autoencoder Latent Space
◼️Multimodal Evaluation of Russian-language Architectures
◼️Wikontic: Constructing Wikidata-Aligned, Ontology-Aware Knowledge Graphs with Large Language Models
◼️Out of Distribution, Out of Luck: Process Rewards Misguide Reasoning Models
◼️Confidence Leaps in LLM Reasoning: Early Stopping and Cross-Model Transfer
Студенческий трек
◼️Bring the Apple, Not the Sofa: Impact of Irrelevant Context in Embodied AI Commands on VLA Models
◼️Acceleration of Backpropagation in Linear Layers of Transformer Models Based on Gradient Structure
◼️Detecting Overflow in Compressed Token Representations for Retrieval-Augmented Generation
Трек Demo
◼️DeepPavlov Strikes Back: A Toolkit for Improving LLM Reliability and Trustworthiness
Трек Findings
◼️Feature Drift: How Fine-Tuning Repurposes Representations in LLMs
Воркшоп TeachNLP
◼️From Standard Transformers to Modern LLMs: Bringing Dialogue Models, RAG, and Agents to the Classroom
Воркшоп NLP4MusA
◼️Learning When to Personalize: LLM Based Playlist Generation via Query Taxonomy and Classification
Воркшоп NLP and LLMs for the Iranian Language Family
◼️Shughni Machine Translation Enhanced by Donor Languages
Делимся кадрами из Северной Африки 📷
#AIRIнаКонфе | 0 |
| 9 | Провёл собственное исследование по языкам программирования будущего.
В целом, дядька Боб правильно уловил ветер и выдвинул правильные требования к языку программирования для AI:
- гомоиконичность;
- явные типы;
- никаких скрытых потоков управления;
- контракты встроены в язык.
Но это пока просто идея. Не реализовано даже формальной верификации контрактов. Типы явные, но это скорее аннотации, чем Хиндли-Милнер. Нет алгебраических типов с exhaustive matching (хотя tagged unions упомянуты). Нет вывода типов.
Если цель - ИИ как полноценный разработчик, нужен язык, который максимизирует вероятность того, что сгенерированный им код корректен. Это значит: сильная система типов (компилятор ловит ошибки ИИ), простота (меньше галлюцинаций), достаточный объём кода в обучающих данных, и путь к формальной верификации.
Lean 4 - стратегически самый интересный, но практически самый рискованный. Если через 5-7 лет Lean станет практическим языком программирования, выбравшие его сейчас окажутся впереди всех. Но не сегодня.
На сегодняшний день выделяются два языка.
Rust - первый кандидат. Огромный объём обучающих данных, ИИ пишет на нём уверенно. Borrow checker отсекает ошибки с памятью. Система типов ловит логические ошибки. Verus, rocq-of-rust, Aeneas для верификации. Экосистема зрелая. Один минус - сложность языка увеличивает вероятность, что ИИ сгенерирует компилируемый, но неидиоматичный код. Тем не менее, строгость компилятора это компенсирует.
Ownership-модель - это фундамент, на котором можно строить доказательства.
Правила Rust устраняют настолько много трудноформализуемых случаев, что это делает его одним из самых удобных современных языков для применения формальных методов.
OCaml - второй кандидат. Меньше обучающих данных, но язык проще, и паттерны более предсказуемые. Алгебраические типы и exhaustive pattern matching - идеальный формат для ИИ-генерации: он описывает все случаи, компилятор проверяет, что ИИ ничего не пропустил. Gospel (Generic OCaml SPEcification Language) - tool-agnostic язык формальных спецификаций для OCaml.
Именно поэтому OCaml используется в финтехе. Экосистема, правда, уступает Rust.
Вишенка на торте - Camlp5. Это OCaml с Lisp-синтаксисом. Типы, компиляция, всё как в OCaml, но добавлена гомоиконичность. S-выражение - это одновременно и программа, и структура данных, которую можно анализировать, трансформировать, генерировать другой программой. Это не макросы как синтаксический сахар - это фундаментальное свойство: программа может порождать программы так же естественно, как оперировать числами.
Программирование перестаёт быть написанием инструкций и становится написанием ограничений. Победят языки, в которых спецификацию невозможно написать неоднозначно.
Дейкстра мечтал об этом полвека назад. Но раньше не было генератора, способного превратить спецификацию в код. Теперь он есть - и узкое место сместилось от написания кода к доказательству его корректности.
Это возвращает нас к тому, с чего начался ML (Робина Милнера) - к языку, созданному для доказательства теорем. Круг замыкается.
Милнер в начале 1970-х в Эдинбурге строил LCF - Logic for Computable Functions - систему для доказательства теорем. Ему нужен был язык, в котором на уровне системы типов невозможно было бы сконструировать невалидное доказательство. Так появился ML - Meta Language.
Пятьдесят лет спустя мы приходим к той же задаче, только с другой стороны. Милнер хотел, чтобы человек писал доказательства, а машина их проверяла. Мы идём к тому, что машина будет писать код, а формальная система - проверять его корректность. Задача та же - гарантия корректности через типы. Только роли поменялись.
ML был создан как язык для мира, где код должен быть доказуемо правильным. Этот мир тогда не наступил, потому что индустрии было важнее "быстро и дёшево", чем "правильно". Но если генерация кода становится бесплатной, а цена ошибки растёт - "правильно" побеждает. И оказывается, что фундамент для этого был заложен полвека назад в Эдинбурге. | 0 |
| 10 | Провёл собственное исследование по языкам программирования будущего.
В целом, дядька Боб правильно уловил ветер и выдвинул правильные требования к языку программирования для AI:
- гомоиконичность;
- явные типы;
- никаких скрытых потоков управления;
- контракты встроены в язык.
Но это пока просто идея. Не реализовано даже формальной верификации контрактов. Типы явные, но это скорее аннотации, чем Хиндли-Милнер. Нет алгебраических типов с exhaustive matching (хотя tagged unions упомянуты). Нет вывода типов.
Если цель - ИИ как полноценный разработчик, нужен язык, который максимизирует вероятность того, что сгенерированный им код корректен. Это значит: сильная система типов (компилятор ловит ошибки ИИ), простота (меньше галлюцинаций), достаточный объём кода в обучающих данных, и путь к формальной верификации.
Lean 4 - стратегически самый интересный, но практически самый рискованный. Если через 5-7 лет Lean станет практическим языком программирования, выбравшие его сейчас окажутся впереди всех. Но не сегодня.
На сегодняшний день выделяются два языка.
Rust - первый кандидат. Огромный объём обучающих данных, ИИ пишет на нём уверенно. Borrow checker отсекает ошибки с памятью. Система типов ловит логические ошибки. Verus, rocq-of-rust, Aeneas для верификации. Экосистема зрелая. Один минус - сложность языка увеличивает вероятность, что ИИ сгенерирует компилируемый, но неидиоматичный код. Тем не менее, строгость компилятора это компенсирует.
Ownership-модель - это фундамент, на котором можно строить доказательства.
Правила Rust устраняют настолько много трудноформализуемых случаев, что это делает его одним из самых удобных современных языков для применения формальных методов.
OCaml - второй кандидат. Меньше обучающих данных, но язык проще, и паттерны более предсказуемые. Алгебраические типы и exhaustive pattern matching - идеальный формат для ИИ-генерации: он описывает все случаи, компилятор проверяет, что ИИ ничего не пропустил. Gospel (Generic OCaml SPEcification Language) - tool-agnostic язык формальных спецификаций для OCaml.
Именно поэтому OCaml используется в финтехе. Экосистема, правда, уступает Rust.
Вишенка на торте - Camlp5. Это OCaml с Lisp-синтаксисом. Типы, компиляция, всё как в OCaml, но добавлена гомоиконичность. S-выражение - это одновременно и программа, и структура данных, которую можно анализировать, трансформировать, генерировать другой программой. Это не макросы как синтаксический сахар - это фундаментальное свойство: программа может порождать программы так же естественно, как оперировать числами.
Программирование перестаёт быть написанием инструкций и становится написанием ограничений. Победят языки, в которых спецификацию невозможно написать неоднозначно.
Дейкстра мечтал об этом полвека назад. Но раньше не было генератора, способного превратить спецификацию в код. Теперь он есть - и узкое место сместилось от написания кода к доказательству его корректности.
Это возвращает нас к тому, с чего начался ML (Робина Милнера) - к языку, созданному для доказательства теорем. Круг замыкается.
Милнер в начале 1970-х в Эдинбурге строил LCF - Logic for Computable Functions - систему для доказательства теорем. Ему нужен был язык, в котором на уровне системы типов невозможно было бы сконструировать невалидное доказательство. Так появился ML - Meta Language.
Пятьдесят лет спустя мы приходим к той же задаче, только с другой стороны. Милнер хотел, чтобы человек писал доказательства, а машина их проверяла. Мы идём к тому, что машина будет писать код, а формальная система - проверять его корректность. Задача та же - гарантия корректности через типы. Только роли поменялись.
ML был создан как язык для мира, где код должен быть доказуемо правильным. Этот мир тогда не наступил, потому что индустрии было важнее "быстро и дёшево", чем "правильно". Но если генерация кода становится бесплатной, а цена ошибки растёт - "правильно" побеждает. И оказывается, что фундамент для этого был заложен полвека назад в Эдинбурге. | 0 |
| 11 | https://github.com/vladikk/modularity от Vlad Khononov. | 0 |
| 12 |  +1Постепенно анализирую тренды через структуру вакансий архитектора, включая прошлый год.
Покрутил данные через opus 4.6, получил интересные выводы.
Категории – это кластеры, в которые собираются отдельные требования и обязанности.
Обозначения
🔴 Вымирает
AI полностью выполняет задачу. Человеку не нужно понимать механику для получения правильного результата. Ошибку можно проверить без глубокого знания.
🟡 Трансформируется
AI выполняет задачу, но без человека с пониманием контекста результат регулярно неверный или неприменим к конкретной ситуации. Человек нужен как «переводчик» между реальностью и AI.
🟢 Растет в цене
AI не может получить нужный контекст в принципе, потому что он существует вне текста: в организации, в истории решений, в неявных требованиях заказчика, в понимании цены ошибки. | 0 |
| 13 | The Architecture of Open Source Applications
В этих книгах авторы нескольких десятков приложений с открытым исходным кодом рассказывают об архитектуре своего программного обеспечения и объясняют принятые решения. Каковы основные компоненты каждой программы? Как они взаимодействуют между собой? И чему научились их создатели в процессе разработки? Отвечая на эти вопросы, авторы книг дают уникальное представление о том, как они мыслят.
Все в открытом доступе.
https://aosabook.org/en/ | 0 |
| 14 |  В 2019-м году выступал на первой (закрытой, поэтому записи нет) конференции Tinkoff Agile Days (тогда она так называлась) c темой «Влияние зависимостей на взаимодействие». Фактически для управленцев через архитектурные, инженерные законы и принципы, с формулами и цифрами, рассказывал о том, как масштабировать орг структуру. И там были такие выводы:
▪️При росте сокращать до возможного минимума количество вовлеченных в принятие решений заинтересованных лиц (N^2)
▪️Масштабирование за счет
▪️небольших автономных команд (2x7 > 14)
▪️небольших автономных компаний
▪️Повышение автономии в принятии решений
▪️От 80% работы внутри границ команды
▪️100% утилизация остановит работу всех, кто от вас зависит
▪️Самоорганизация или «Если бы птицы согласовывали структуру стаи?»
▪️При физической работе увеличение размера увеличивает эффективность, а основные конкуренты — крупные организации
▪️При интеллектуальной деятельности меньший размер увеличивает эффективность, а основные конкуренты — небольшие компании с хорошим опытом
▪️Субподрядчик принесет увеличение эффективности, если он самостоятелен и его можно игнорировать
Просто посмотрите на это с точки зрения оснований и тактик масштабирования в архитектуре :) | 0 |
| 15 |  Counter-Strike и смерть за укрытием
Вот в этом видео https://www.youtube.com/shorts/1m27HIyluIQ наглядно показана известная ситуация, когда игрок успел спрятаться за стену и в этот момент был убит. На уровне ощущений это выглядит будто пуля завернула за угол. Но архитектурно это не "пуля догнала в настоящем", а сервер признал, что было попадание в своём восстановленном прошлом. Valve прямо описывает такие парадоксы как lag compensation: можно получить попадание уже после того, как вы на своём экране ушли за укрытие.
Базовая онтология Counter-Strike - это authoritative server: сервер владеет симуляцией мира, а клиент в основном отправляет команды и получает обновления состояния. Чтобы игра ощущалась отзывчивой, клиент предсказывает свои локальные действия, но окончательная истина всё равно принадлежит серверу. Yahn Bernier описывал это для Valve-шутеров примерно так: клиент может временно предсказывать движение, но authoritative server в итоге исправляет расхождения.
И вот здесь рождается ключевой трюк - lag compensation. Когда на сервер приходит команда выстрела, он не проверяет попадание только по "текущему" состоянию мира. Он пытается реконструировать, что именно видел стрелок в момент нажатия, и для этого отматывает позиции других игроков назад по истории состояний. В документации Valve это прямо формулируется как rewind: сервер использует latency игрока, чтобы "вернуться во времени" при обработке команды и увидеть мир так, как его видел стрелок. А у Bernier эта же идея описана как нормализация мира на сервере к моменту действия игрока.
Поэтому смерть "за укрытием" - это не баг, а цена архитектуры. Если бы сервер не делал такой rewind, игрокам с более высоким пингом пришлось бы стрелять с упреждением не только по движению цели, но и по сети: буквально целиться в место, где противник будет через десятки миллисекунд. Lag compensation нужен именно для того, чтобы стрелок мог целиться туда, где он реально видел цель, а не вручную компенсировать задержку. Но симметричная цена этого решения в том, что жертва иногда умирает уже после того, как на своём экране спряталась.
Парадокс усиливает ещё одна вещь - interpolation. В сетевых шутерах клиент обычно показывает других игроков не в абсолютном "сейчас", а с небольшим буфером по истории, чтобы движение было гладким и не дёргалось от потерь пакетов. Bernier отдельно подчёркивал, что interpolation - это тоже форма латентности, и её надо учитывать при проектировании lag compensation. То есть у нас уже есть два времени: локальное "сейчас" и тот немного задержанный образ противника, по которому реально целится стрелок.
В CS2 Valve добавила ещё и sub-tick architecture: сервер теперь знает точный момент, когда началось движение, был сделан выстрел или брошена граната. Это делает тайминг точнее, но не отменяет саму онтологию. Точное время не убирает тот факт, что попадание в Counter-Strike, это решение authoritative runtime над реконструированным прошлым, а не простая физика "что я сейчас вижу на своём экране".
Именно поэтому мне нравится смотреть на Counter-Strike через призму inversion of control.
В локальной игре нам кажется, что причинность принадлежит клиенту:
я навёлся, я нажал fire, я попал.
В сетевом Counter-Strike это не так. Клиент не владеет фактом попадания. Это по сути архитектура интентов, но в CS, потому что по факту клиент публикует intent, выраженный в форме команды. А дальше уже внешний рантайм, то есть authoritative server, решает, в каком историческом срезе мира этот выстрел должен быть интерпретирован. Иными словами:
не
player fires -> target dies
а
player submits intent -> server reconstructs world -> hit becomes valid or not
Это и есть настоящая инверсия контроля, при которой нет управления собственным выстрелом до конца, но он передаётся в чужой control plane, который уже им управляет.
P.S. А ещё этот пример демонстрирует, что (трендовая в 2025 году во всяких блокчейнах) архитектура интентов - это тоже есть форма инверсии контроля на уровне исполнения. | 0 |
| 16 |  Как архитектор готовится к передаче системы в эксплуатацию
Тимофеев Денис
Cloud.ru
Передача в системы в эксплуатацию - это не дело архитектора
Именно так начинается это выступление :)
Денис сразу начинает с того, что архитектор – это уже одной ногой владелец продукта, что в целом отражает тенденции отрасли. Но тут же делает разворот – это не все, об инфраструктуре теперь тоже нужно думать и думать куда больше, чем архитектор думал об этом раньше.
Выступление раскладывает деятельность через системный подход – сразу отделяя структуру (инфру) от функции (конкретные рабочие процесс). Далее повествование строится вокруг инфраструктуры.
Пожалуй, стоит привести цитату Дениса, которая точно отражает на концептуальном уровне, что вообще такое передача в эксплуатацию: «Передача в эксплуатацию – это изменение ответственности за эксплуатационные задачи конкретной ИС».
А дальше... А дальше придется смотреть само видео, потому что рассказать его суть - это рассказать буквально все, в выступлении плотный и конкретный контент:
- Чеклист передачи в эксплуатацию
- Процесс приемки, описанный по шагам
- Вовлеченные роли
- Отработка инцидента
Отличное, легкое для просмотра и емкое выступление ✍️
VK: https://vk.com/video-184472537_456239210
Youtube: https://youtu.be/g8rEUA8iPjc | 0 |
