Architecture assessment from classics to details [ukr]

Дякую, по-перше, що досиділи до кінця. Я буду тут ходити по сцені, махати руками, щось показувати на слайді. Давайте почнемо з інтерактиву. Мені цікаво зрозуміти, з ким ми спілкуємося. Вже сьогодні була панелька: хто є architects в цій залі? Окей, супер. Хто є tim leeds, seniors? Ого, нормально, круто. Окей, хто хоче стати architects? Хто знає, як стати architects? Окей, супер, добре. Хто в аутсорсингу працює? Небагато? Ого. А продукти? Ого, круто, добре. Сьогодні трошки буде про консультантів, але це також відноситься і до продуктів. Окей, почнемо. Архітектурні рішення дуже прості. Ви маєте зрозуміти, що нам треба зробити, зробити рішення і пояснити його все. Дякую. Розходимось.

Один дядько розумний сказав таку фразу, що "Той самий мозок або майнд не може вирішити складену проблему, або яку вони створили." Хто з цим погоджується? Тому дякую. Та він ще теорію відносності, мені здається, написав. І саме цей рул та для багатьох бізнесів говорить про те, що ми маємо запросити когось зі сторони, щоб нам допомогли розібратися в нашій проблемі. Не тому, що ми не довіряємо нашій команді, а тому, що ми хочемо інший погляд. Іноді для команди, яка вже занурена в сварках зі своїм менеджментом, чому нам треба щось там зробити, щось поміняти, перейти в сервісну архітектуру, теж потрібен хтось зі сторони, щоб він підсупортив.

Таке буває. Так, окей, де працює приблизно архітект? Ми говорили сьогодні про цей ліфт. Коли архітект мотається з верхніх поверхів, десь насередині з middle management, потім в подвал, де сидять operations команда або розробники, і нагору. І так от, ганяє інформацію туди-сюди. В цілому, якщо так подивитись, інший зріс, з чого все починається. І це, до речі, не тільки до консультантів відноситься. Це і в продуктах так само. Навіть якщо ми працюємо в продукті, мені все одно треба підготувати певну ідею, таку фізабіліті стаді зробити і показати це моїм owners. Якщо вони це купують, ми можемо погрузитись трошки детальніше, зробити якісь PFC, вже більше детальну архітектуру, і ми це зробимо по типу discovery. Такий є термін, він в багатьох книгах описаний.

Далі, якщо все круто, є детальні estimates, є детальна архітектура, ми розуміємо, як іти, і команда, і так далі, ми стартуємо імплементацію. Всі, хто в продуктах, зачасту крутяться десь тут. Ті, хто в аутсорсі архітекти, вони крутяться в зелених фазах, тому що їх здебільшого наймають на консультантів. В багатьох компаніях архітекти і на імплементації теж працюють. І, в принципі, архітект займається чим? Він готує візію для чогось нового і може, давайте так, аналізувати, що існує. І сьогодні поговоримо саме про assessments. Але швидко. Я буду десь сказати, що можна дочитати, тому що нам 40 хвилин не вистачить.

Якщо в деталях подивитись на assessments, з чим ми взагалі стикаємося, що нам треба робити, як архітектам, то перше, нам треба підготуватись. Нам треба розуміти, що ми будемо робити. Що це за компанія, моя внутрішня компанія, якийсь певний проєкт або SAP-проєкт і так далі. Мені треба підготувати адженду, якщо це якась фіксована буде фаза. Всякі там архітектурні темпліти, non-functional requirements, квестіонарії, tool set для assessments. І далі я стартую, в принципі, мій assessments. Дуже часто на assessments в нас є архітекти, ряд експертів, тому що сьогодні вже сміяли, що архітект – космонавт.

Космонавту треба ще й інженери для deep-dive, оскільки архітектори – це нормально, вони не знають все. Тому їм треба певний knowledge, хто може їм допомогти. Якщо це консультанти, то це можуть бути селі, клайн-партнери, менеджери різних рівнів і так далі. Дуже прості стадії. Перше – це ми збираємо requirements, business case і так далі малюємо, далі – non-functional requirements. Тому що для архітектури, non-functional requirements – це ключове. Це наше ядро, на яке ми концентруємося як архітекти. Далі робиться review, коли ми зібрали драйвери. Драйвери – це requirements, що буде нас спонукати в майбутньому в дизайні, еволюції тощо. Далі зібрали ці драйвери і сьогодні ми говоритимемо про quantitative, equality of analysis.

Quantitative – це все про цифри. Мені треба якось поміряти проєкт. Якщо я з ним не знайомий, мені треба витягти, наприклад, кількість строк коду. Я можу запустити різні тести – лого-тестування, стрес-тестинг, може хаос. Мені треба підключити моніторинг-агенти, якщо їх немає, якийсь моніторинг. Також потрібно провести security-тестування, accessibility-тестинг і так далі. Купа тестів, щоб зрозуміти, з чого складається мій продукт в цифрах. Також потрібен якісний аналіз. У мене є Non-Functional Requirements, Business Goals, Constraints. І є певні прийняті рішення. Навіть якщо вони не візуалізовані, рішення прийняті в проєкті є. Це патерн великого вибуху. Якісь рішення прийняті, але архітектура не завжди візуалізована. Тому як архітектор, виходячи з драйверів, ви формуєте їх у прийняті рішення.

Наприклад, якщо хтось вирішив використовувати SAP, це прийняте рішення, і ви як архітектор аналізуєте його в контексті даних реквірментів. Далі робите set рекомендацій, пишете звіт і комунікуєте його. Щодо того, коли робити assessments, то чим швидше, тим краще, існує думка, що архітектурні assessments, аудити, рев'ю current state і так далі потрібно робити регулярно. Бізнес, мейнтенанс, погана продуктивність – це кілька причин, чому вони можуть знадобитися. Так що, взагалі, коли це потрібно – це відповідь на ситуацію. Якщо щось працює, і немає проблем – можливо, не потрібно. Якщо є певні проблеми або питання – тоді це вже відповідь, що потрібно робити assessments.

Вся архітектурна методологія, незалежно від того, що ви читаєте в будь-яких книгах, в принципі призводить нас до необхідності утримувати причинно-наслідковий зв'язок в усіх прийнятих рішеннях. У будь-якому рішенні, яке ви приймаєте, повинен бути причинно-наслідковий зв'язок. Перша проблема: приходить когось молодшого і каже: "Ми повинні перейти на мікросервіси." Я питаю: "Чому?" Та відповідають: "Це круто, я прочитав книгу про міграцію до мікросервісів. У нас є моноліт, демон. Деплоїти це складно, і взагалі є проблеми з продуктивністю."

Я говорю: "Чудово, добре зроблено. Але можливо, замість мікросервісів нам підійде MicroKernel?" У нас є плагін-система, і вона порушена. Я запитую, що нас підштовхує до цього рішення. Тут аудиторія вже говорить. Бізнес може впливати на рішення, додаючи Non-Functional Requirements, такі як Maintenance, Availability, Scale та інші. Ми повинні це зібрати. Ми проводимо assessments або робимо дизайн нових рішень. Завжди є три простих кроки. Перший - це збір нашого контексту, драйверів. Далі - прийняття рішень та аналіз, тестування.

Як ми збираємо реквірменти, ви всі, сподіваюсь, знаєте, що це Business Goals, Functional та Non-Functional Requirements, Ризики, Constraints, Concerns. Все це. Щодо дизайну, існують різні методології та фреймворки. В світі існують практики від Software Engineering Institute Carnegie Mellon в Сполучених Штатах. Вони базуються на трьох книгах, на яких ґрунтується більшість компаній та воркшопів, які ми проводимо на Fwdays та інших платформах. Так що ADD, View and Beyond, Quality Attribute Workshop і т.д. Ми часто використовуємо метод оцінки архітектури 3D, як на етапі дизайну, так і при аналізі чужих архітектур. Ми можемо випробувати його, створивши прототипи, надавши його на рев'ю тощо.

Але це також потрібно робити правильно та завжди тримати в голові резон. У мене є певні реквірменти, і мені хтось їх пріоритизував. Хто повинен пріоритизувати реквірменти? Бізнес, дякую. Це було правильно. Бізнес повинен це робити. Далі я приймаю рішення відповідно до цих реквірментів. Це може бути декілька варіантів, багато дизайну і так далі. Але я дію згідно з тими пріоритетами, які мені надали... Якщо мені сказали, що еволюабіліті - це наше головне, або масштабованість та інші, я буду туди концентруватися. Мої патерни і стилі будуть відповідати цим пріоритетам. Я пояснюю це під час аналізу методів. Я пояснюю бізнесу, що я прийняв рішення, тому що ви дали мені такий реквірмент, а не тому, що мені хочеться мікросервісну архітектуру.

Окей? Супер. Дуже швидко. Перший етап аналізу робиться, коли ви створюєте власні рішення з нуля. Ви будуєте нову систему або вносите зміни до існуючої. Це ADD. Швидко. Не потрібно поглиблюватися в деталі. Перший мій крок - декомпозиція. Я збираю реквірменти. Далі я декомпозую свою систему на логічні частини та застосовую до них свої реквірменти. Потім ви бачите плеяду аналізу всього світу.

Отже, це тактики, патерни, стилі, референс-архітектури, референс-моделі і так далі. Я повинен взяти щось із цього для моїх конкретних вимог. Що найкраще підходить для мого специфічного випадку? Потім, я не можу просто передати інженерам або клієнту просто паттерн, взяти його, переробити або скопіювати з Інтернету. Це неприйнятно, оскільки це вже дуже загально. Мені потрібно взяти патерн і перевести його на мій продукт, у мій контекст, відповідно до моїх вимог і декомпозиції системи. Потім я повинен задокументувати це, виділити інтерфейси і так далі. Що далі? Провести аналіз своїм власним рішенням. Я повинен пояснити собі і своїм зацікавленим сторонам, бізнесу та інженерам, чому я прийняв це рішення.

В будь-якому архітектурному рішенні є вплив на витрати. Кожне ваше рішення впливає на витрати. Ви можете вважати, що написання юніт-тестів є романтичним і підвищує якість. Але будь-яка річ, яка підвищує якість, коштує гроші. Це факт, це аксіома. У нас можуть бути ризики. Моє рішення може якось негативно впливати. Я повинен ідентифікувати їх, визначити пріоритети та придумати стратегію зменшення ризиків (mitigation strategy). Що таке стратегія зменшення ризиків? Це нове архітектурне рішення. От і все, круг замкнувся.

Після мого аналізу можуть з'явитися нові драйвери і компроміси (trade-off). Що таке компроміс? Це архітектура. Будь-яка архітектура ґрунтується на компромісах. Я роблю щось більше в одному місці, менше в іншому. Працюю в галузі систем охорони здоров'я. Хто з вас коли-небудь мав справу із стандартами HIPAA? Дякую. Класно. Зрозуміло. Система охорони здоров'я (healthcare) має свої регуляції. Зараз якраз підпадає під HIPAA в США, PIPEDA в Канаді, NHS в UK, і так далі. Є певні стандарти. І вони кажуть: "Ваші комунікації між застосунком та базою даних повинні бути захищеними." Коли ми будуємо наші системи, ми можемо мати non-secure connection, але все повинно бути secure. Ми повинні це показати, довести і так далі.

Мої дані в базі даних повинні бути зашифровані. Якщо я це роблю, що може статися? Продуктивність може значно знизитися. І я це роблю навмисно. Не тому, що я хочу погіршити продуктивність, але тому, що у мене є драйвер. У мене є стандарт, якого я повинен досягти. Ми завжди щось жертвуємо. Це trade-off. Добре, зрозуміло. Так що ми робимо наш аналіз. Як тільки ми генеруємо певні рішення, ми відразу ж переходимо до аналізу і показуємо причину, чому ми прийняли те чи інше рішення. Ось як виглядає architecture decision log або architectural view.

Architecture decision log виглядає трошки інакше. Він більш простий. Але будь-яка архітектурна view, яка розкриває певні рішення, будується приблизно так. Ми не глибоко вдаваємось в неї. У мене є намір. Це розділ, де я, як архітектор, кажу, що я хочу досягти в цій view, яке вимагає певного рішення чи вимоги. Далі є контекст, в якому я приймаю це рішення. Контекст може включати політичні аспекти, архітектурні обмеження і так далі. Це, щоб через рік-два, відкривши цей документ, я міг зрозуміти, які обставини були тоді, коли команда не знала Java, але клієнт вимагав використання Java. Це хороший контекст. Далі йде репрезентація. Це частина вибору патернів, тактик і так далі. Мені потрібна візуалізація. У мене є діаграма і опис. Хто з вас отримував варіанти, коли вам показували діаграму і казали: "Це моя архітектура", без опису? Зрозуміло. Ця архітектура розуміється тільки людиною, яка її малює, в певний період часу.

Через рік і можливо навіть більше, людина може забути, що саме означають стрілочки на діаграмі та як все було виконано. Вона не завжди згадує, чому вибрані саме такі стрілочки та інші деталі. Тому будь-яка візія, будь-яка репрезентація та діаграма повинні містити пояснення. Це своєрідний каталог елементів, що складають візуальне представлення паттернів та рішень, і чому саме були обрані певні елементи. Це також стосується зв'язків, які теж потрібно пояснити, якщо ви не використовуєте напівструктуровані стандарти, такі як UML або структуровані, наприклад, Archimate, де все вже визначено. Також можна виділити інтерфейси та поведінку (behavior). Наприклад, на діаграмі може бути представлено, як взаємодіють різні частини системи в різних сценаріях, таких як Activity чи Sequence діаграми. Також важливо враховувати можливі варіації у різних середовищах (наприклад, в Production та QA).

Важливо визначити "Reasoning" або обгрунтування. Тут можна пояснити, чому обрано певні рішення. Наприклад, може бути позначено, які аспекти допомагають або заважають вирішенню певних проблем чи задач. Реальний кейс може включати драйвери, вимоги, прийняті рішення, аналіз, чутливість до змін, ризики та їхні неможливісті. Коли інженери приходять, архітектор може пояснити свої вибори, показати, як вони пов'язані із вимогами, та передати докладніше обгрунтування. Це допомагає забезпечити зрозуміння інженерам та іншим членам команди.

Інша важлива частина - це процес будування рішення (solution). Це включає в себе прийняття рішень, які базуються на драйверах (drivers), декомпозиції вимог та сценаріїв. Кожне прийняте рішення має свою обгрунтовану причину, де фітнес-функції (fitness functions) можуть використовуватися для тестування невід'ємних вимог. Також може важливим бути визначення "фітнес-функцій" для вимірювання та оцінки архітектурних рішень. Наприклад, вимірювання продуктивності, завантаження та інших нефункціональних атрибутів. Основна ідея - визначити, як саме рішення впливає на ті аспекти, які є важливими для системи.

Нарешті, є процес евалюації (evaluation) за допомогою методу ATAM (Architecture Tradeoff Analysis Method). Це більш детальний підхід, що дозволяє провести об'єктивний аналіз та оцінку архітектурних рішень. ATAM включає в себе детальний аналіз драйверів, варіантів рішень, альтернатив та їхніх впливів на систему. В цілому, вся ця система допомагає забезпечити зрозуміння та обгрунтованість при прийнятті архітектурних рішень, сприяє взаєморозумінню між архітекторами та інженерами, і допомагає у вирішенні проблем та прийнятті оптимальних рішень для проекту.

Тепер, коли ми приходимо на проект як архітекти і повинні рев'ювати чужі рішення, це стає складнішим завданням. Якщо ви консультант і приходите в іншу компанію, ви можете спостерігати позитивний прийом з боку архітектурної команди. Однак, коли ви приступаєте до роботи з існуючим проєктом, може виникнути тертя через невизначеність і обмеженість ресурсів. Архітект, який вирушає робити assessments в іншій компанії, повинен мати чітку систему дій. Він не повинен приймати ад-хок рішень, але має мати структурований підхід.

Перший крок у цьому процесі - це збір реквайрментів. Але при assessments цього може бути недостатньо. Клієнт може вказати на деякі проблеми, але потрібно докладніше розібратися. Тому, окрім реквайрментів, потрібно працювати із сценаріями якісних атрибутів (quality attribute scenarios). Далі, архітект проводить різні воркшопи та брейншторминг, спрямовані на виділення сценаріїв та метрик. Також важливо отримати всю доступну інформацію від клієнта, таку як весь код, інфраструктуру, результати тестування, звіти з безпеки та відповідність.

Для ефективного розуміння проєкту архітект повинен враховувати, що на багатьох проєктах немає достатньої документації, тому він повинен бути готовий вивчати код та реалізацію. Важливо візуалізувати прийняті рішення через цифри та об'єктивно довести клієнту, що його цілі, які можуть бути представлені в цифрах, не є досяжними або мають певні ризики. Для цього робиться два типи аналізів - кількісний і якісний. Основний акцент робиться на аналізі компромісів та ризиків. Після цього архітект може створити рекомендації, що включають нові рішення, їхній вплив на існуючу архітектуру, часові оцінки, плани вдосконалення та показники успішності. У процесі роботи архітектору важливо поставити очікування для себе та клієнта. Використовуючи індикатори успіху в роудмапі, архітект може стежити за прогресом та впроваджувати тести для перевірки правильності рекомендацій. Важливо показати клієнту, що його цілі можуть бути досягнуті через певні кроки і покращення, а не просто базуватися на обіцянках чи віри.

Дуже круті тули. Це Structure 101. Якщо не бачили, то було б непогано подивитись. Але воно супортує Java, .NET і Python, здається. Я не впевнений про інші мови програмування. Мої проєкти зачасту – це Java або .NET. Це Enterprise, суровий, тому десь так. Був ще COBOL, але Structure 101 теж не супортує. Latix – це десь такий самий, як Structure 101. Що воно показує? Ви можете побачити свої пекеджі, наприклад. Високий рівень, потім зробити більш приземлений, декомпозицію. Ви можете подивитись Cyclomatic Dependency, як один пекедж з іншим пов'язаний. Де архітектурно знаходиться структура.

Дуже крутий тул, тому що ми можемо швидко з коду візуалізувати архітектурну декомпозицію. Всякі Ovasp і так далі телефони архітектори часто запускають для керівників thereafter на áAzom ASA. Blaentoam, G preacher, Gatling, K6 Я думаю, що хтось з вас їх використовував. BlazeMeter – це SaaS-платформа. Але всі інші – це, в принципі, для лоу-тестування. Gmeter, мабуть, найпопулярніший. Але останні проекти в мене на K6 BlazeMeter чим прикольний? Тим, що ви такі просто можете for free 50 конкурент-юзерів підняти агента, load agent в Амазоні І побомбити там якийсь ресурс Прикольно. А ще є плагіни в Хромі. Можете записати свої сценарії. Якщо ви не розбираєтесь взагалі в перформанс-тестуванні То, в принципі, це непоганий тул Подивитись, що відбувається. Я колись подивився і вклав в продакшн.

Тому треба попереджати клієнта, що ви щось будете робити. А якщо ви робите щось таке прям суттєве То ви маєте ще попередити клауд-провайдера Або інфраструктур-оунера. Що ви будете робити певний тип тестування Або security, або перформанс Тому що вас можуть просто що Забанити, правда? Всякі сценар-к'юби, всім відомі Чекмакси, та це тули Ну, понятно, для код-аналізу Чекмакс для security Sparse Enterprise, Archimate і Draw.io Це для документації, New Relic і так далі Це для Для Application Performance Monitoring І всякі ADR-тулзи Для Decision Logs Якщо щось таке є, то це прикольно було Подивитись у клієнта. Які їх були логи.

Assignment template десь виглядає таким чином. Є, Специфікація документації архітектурної. Є різні, ISO стандарт по документації. Є TOGO вський стандарт Інтерпрайз архітектури Є оцей ARC-42 Дуже попсова така річ Типу архітектура для блондинок А є View and Beyond Теж, в принципі, десь на рівні концепції. До TOGO фа не дотягує, але в принципі можна непогано дотягувати до того, що є в цьому таборі Для себе адаптувати View and Beyond означає, що в мене є в'юшки і щось зверху. Тому, якщо взяти наш assignment репорт, то в нас є Beyond. Це все, що там scope.

Для кого ми це робимо. Різні референси, акроніми і так далі Outcomes Executive Summary. Executive Summary дуже часто читають всі технічні люди. А далі вже не цікаво тут я почитав основну суть, клас. Якщо ти бізнес-аналітик або QLE То ти будеш далі читати драйвери. Наш перший степ це зібрати реквіарменти тому має бути десь на то секція. Далі в мене йде архітектурне в'ю. В TOGO фі є проста концепція. Маємо розуміти, що зараз і куди рухаємось. А потім геп між ними. Так і в архітектурі так само. Маємо відвізуалізувати Current State І далі, в принципі, наш аналіз. Quantitative Equality Analyse. Там є якісний кількісний аналіз. Кількісний трошки займає часу.

Я не знаю, лотести. Ці всі репорти. Воно займає певний простір. Тому дуже часто архітекти виносять це в апендікс. Це така десь підвальна частина документу. Ця чернетка там. Тут ми виносимо summary. Що там ви не досягаєте тієї кількості юзерів, або concurrent trade. Які ви нам сетили, тому що от в мене є репорт. Потім ідуть секції з рекомендаціями, оцінкою ризиків і improvement roadmap. Все по тому процесу, який я показував в діаграмі. Ну я вже майже закінчив. Соціальна мережа. Я цей кейс постійно розказую, тому що він такий показовий. Соціальна мережа для дітей і батьків. Батьки менеджери. Коротше, навішують таски для дітей, накидують їм таски. Вони там винесуть сміття, я не знаю. Дитинка щось там виконає, от потім їй дають бонуси. Вона ці бонуси може обміняти на баблішко в Амазоні. Все, дуже класна така мотиваційна штука.

Почався, так давай і роботай. Коротше, в них що було. Було мобільні аплікації, була адмінська аплікація, де батьки могли нагенерувати цих тасок. Це якийсь там Linode Path, платформа за сервіс, аля Хіроку. В них був один Ubuntu серверок, де крутилась Noda. Була крон-джоба, і був якийсь S3. І база даних не показує. І їхні реквайрменти. Ми хочемо там певну латентність - 2 секунди. Ми хочемо 1000 simultaneous або concurrent юзерів, це такі, які одночасно щось роблять в системі. І що ще там? Швидкі ресторани і так далі. Це все, немає не балансерів, нічого. Це от все, комплітлі аплікаційна архітектура для мобайл і веб клієнту. Одна відмінність. Якщо розбиратись з цією архітектурою, то в принципі вона проста. Вона не коштує дорого. Є певний ризик за цим. Це швидко робиться. Ну там Noda закинув, може скластерізував її десь там на корах. Але в цілому досить все симпатично. Якісь S3 є, все просто, доволі не складно.

Що я роблю? От те, що я зараз проговорю, то я і записую. Як архітект, що вони використовують, такий-то Linode сервіс. Це є рішення, правда? Я його записую. Використовуємо Linode. Далі в мене там є Noda. От що бачу, то і пишу. Це ж прийняте рішення кимось. Я його записую. Ну і так далі. Там метеор кластери, там сінгл Noda, яка там 40 тисяч реквестів два рази на день запускає. Вони до речі прийшли і кажуть: 'В нас система недоступна два рази на день.' Я кажу, що значить недоступна. Ну взагалі все ерор. Два рази, і ти потім дивишся моніторинг, і там Cron Jobs просто два рази запускається в сутки і просто фігачить аплікацію.

Оцей. В момент, коли на ньому сидять юзери, і воно все просто CPU входить в 100%. І далі сервер залипає. Є такий момент. Все, і я підкреслюю там, є певні позитивні поінти там використовувати Linode. Ну і я їх пояснюю. Далі клієнту, що це просто круто. Але якщо ви хочете досягти тисячі simultaneous юзерів, цього цієї архітектури недостатньо. Треба скейл, правда? Це, мабуть, найбільше і популярне рішення. Далі я це все прописую, пояснюю. Я посилаюсь на результати в процесі виправлень.

І це я роблю якісний аналіз. Тобі ж в мене є requirement. Є прийняті рішення. В мене є аналіз. В мене є результати перфоменс чи security тестування, де я доказую клієнту: "Дивись, в тебе не буде досягатись твій measurement, із-за того що я ось зробив тести твоєї current системи. Все просто." І клієнт такий: "Ну, да, все чотко. Що ти пропонуєш?" Я пропоную тобі зробити impact аналіз і ризик аналіз твоїх ідентифікованих ризиків. Прибігає до мене проджект менеджер і кричить: "Діма, у нас великий ризик!" Я кажу: "Як ти це зрозумів?" Він каже мені: "Клієнт позвонив на телефон." Я такий: "Прикольно. А в тебе немає баг сюррогейті та і пріоріті. Взагалі тобі ж всі баги просто отаким мішком лягають. Я кажу: "А що нам дивитись взагалі? Ну ви якось там розбирайтесь."

А тут вдруг: "Хай пріоріті ризик." Я ніфіга собі ти оцінив. Молодець! Так от щоб правильно оцінювати, ми маємо розуміти probability і impact. Це сама проста формула ідентифікації і пріоритизації ризика. Probabilty - зрозуміло, як часто цей ризик виникає, і impact - на що він вплине, якщо він виникне. Це іноді складно порахувати і доказати клієнту, і самим для себе теж. З тою історією з Cron Jobs все просто. Два рази на день, я це бачу по моніторингу. Сервер недоступний. Probabilty досить часто - два рази на день. Impact - який бізнес не працює. До речі, імпакт це не імпакт на скільки задоволені девопси чи інженери чи архітекти. Це імпакт саме на бізнес. Що буде, якщо ризик виникне? То що буде з бізнесом. Ну і по кейсу з Cron Jobs, це, звісно, дев'ятка. І ми це показуємо, і я це пояснюю клієнту. Він такий: "Це все має сенс." Тому пропоную, що ти пропонуєш. І те, що я буду пропонувати, я показувати не буду, тому що це довго. На цьому все. Дякую за увагу. Питання?