Порівнюйте відповідальність до порівняння продуктів

Порівнюйте той самий результат

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

Асистент програмування, внутрішня платформа та фабрика програмного забезпечення можуть розв’язувати різні частини проблеми. Порівняння цін підписок без визначення обсягу може привести до хибного рішення.

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

Для вигаданого сервісу договорів організації потрібні схвалені вимоги, доступ працівників, приватні записи, перевірені випуски, реагування на інциденти та постійні оновлення. Інструмент, що генерує endpoint, виконує частину цього списку.

Опишіть три можливі операційні моделі

З асистентом програмування розробники використовують ШІ в наявній інженерній системі. Організація надає навколишні процеси, інтеграції, можливості платформи та збирання доказів. Це може підходити організації зі зрілими спільними сервісами.

У внутрішньо зібраній системі доставки організація інтегрує агентів, контекст, перевірки, розгортання та операційний зворотний зв’язок. Вона отримує контроль над дизайном і також відповідає за інтеграційний продукт, його підтримку та оновлення.

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

Це моделі порівняння, а не універсальні категорії продуктів. Конкретний постачальник або внутрішня платформа можуть поєднувати можливості інакше.

Перевірте шлях від прототипу до сервісу в експлуатації

Використовуйте той самий конкретний сценарій для кожного варіанта. Для банківського прототипу почніть із синтетичних транзакцій і без прав доступу до реальних систем. Попросіть команду або постачальника продемонструвати ці можливості до розширення доступу:

1. Оцінити прототип і визначити код, який потрібно змінити або замінити.
2. Розгорнути в потрібній інфраструктурі, включно з вашими хмарними обліковими записами, де цього вимагає політика.
3. Перевірити права застосунку, обробку секретів і потоки даних під час розробки та виконання.
4. Створити докази щодо застосовних вимог і записати рішення про випуск.
5. Відстежувати сервіс, виправляти вразливості, перевіряти відновлення та реагувати на інциденти.

Перенесення коду до вашого облікового запису — одна частина цієї роботи. Перевірте, хто може адмініструвати середовище та де зовнішні сервіси отримують дані. Узгоджуйте засоби контролю зі своїми зобов’язаннями; саме розташування розгортання не встановлює відповідності.

Щоб побачити заявлені межі одного постачальника, порівняйте опис спільної відповідальності Taiga зі своєю картою. Це матеріал видавця цього сайту. Перевірте застосовний договір і конфігурацію до увімкнення Taiga.

Розділіть виконання, перевірку та рішення

Для кожної дії запишіть, хто її виконує, хто перевіряє результат і хто приймає наслідок. Одна сторона може мати кілька ролей, але незаповнена роль — це прогалина.

Хмарні сервіси також розподіляють відповідальність між постачальником і замовником. Точний розподіл залежить від сервісу. Використовуйте це як підставу запитати точну карту, а не припускати, що кожен керований продукт має ту саму межу. Спільна відповідальність AWS.

Шукайте прогалини та дублювання роботи

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

І навпаки, постачальник може припускати, що замовник має команду реагування на інциденти, тоді як замовник припускає, що експлуатація включена. Усуньте цю прогалину до того, як користувачі почнуть залежати від сервісу.

Рекомендації CNCF щодо платформ дають організаціям змогу поєднувати внутрішні та керовані можливості. Важливе питання — чи задовольняє отриманий досвід потреби користувачів із чіткою відповідальністю. Рекомендації CNCF.

Використовуйте карту в комерційному рішенні

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

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