Замкніть цикл перевіреним поліпшенням

Визначте цикл, який хочете замкнути

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

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

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

Простежте одне спостереження через життєвий цикл

Послідовність нижче — запропонований інженерний метод. Це не твердження, що будь-який продукт автономно виконує кожен крок.

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

Зберігайте оцінювання незалежним від пропозиції

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

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

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

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

Випустіть і виміряйте результат

Canary-випуск надає обмеженій групі доступ до версії-кандидата. Порівнюйте сигнали кандидата й контрольної версії та визначайте, коли розширювати доступ або зупинятися. Малий трафік чи різні навантаження можуть зробити порівняння непереконливим. Рекомендації щодо canary-випусків.

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

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

Зробіть запис зворотного зв’язку придатним до використання

Використайте для вправи такі поля: спостереження та версія; початковий рівень; запропонована причина; критерії приймання; регресійні перевірки; зміна та перегляд; межа випуску; виміряний результат; відповідальний і наступний перегляд.

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

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