Операції та Управління → Етика операційного управління

Етика операційного управління

1) Навіщо це потрібно

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

• Задати ясні «червоні лінії» і правила поведінки для команд і он-колла.
• Забезпечити чесність SLA, метрик і комунікацій в інцидентах.
• Захистити приватність, дані та права користувачів/партнерів.
• Зробити автоматизацію та АІ керованими, зрозумілими та безпечними.

2) Базові принципи (ядро)

1. Safety first: рішення не повинні підвищувати ймовірність шкоди користувачам/даним.
2. Чесність вимірювань: ніякої «косметики» метрик, єдиний SSOT і відтворюваність.
3. Прозорість дій: хто що зробив, чому, на підставі яких даних.
4. Відповідальність і підзвітність: роль → повноваження → аудит → наслідки.
5. Мінімізація даних: збираємо тільки необхідне, обмежуємо доступ і термін зберігання.
6. Explainable Ops/AI: автоматичні рішення зрозумілі, оборотні і оскаржувані.
7. Справедливість і відсутність дискримінації: політика «no bias» в правилах і моделях.
8. Blameless, але не безсуб'єктно: помилки - привід змінювати систему, а не приховувати факти.

3) Етика метрик, SLO/SLA і звітності

• Єдині визначення метрик (вікна, агрегатори), версіонування формул.
• Заборонено: приховувати інциденти в «планових роботах», переносити вікна/зони часу заради «красивих» SLA, виключати дані без документальної підстави.
• Чітке маркування: «оцінка», «прогноз», «факт», «виняток і підстава».
• Постмортеми публікуються з фактами і діями, а не «PR-взяттям».

Анти-патерни: «дві версії p99», ручне коригування звітів, вибіркові періоди «без піків».

4) Приватність і робота з PII/платіжними даними

Мінімізація: за замовчуванням PII не залишає виробничий контур; маски в логах/дашбордах.
Доступ за ролями: принцип найменших привілеїв; аудит кожного читання чутливих даних.
Retention: чіткі терміни зберігання, політика видалення/анонімізації.
Інциденти з даними: негайне повідомлення власників/юридичних осіб за регламентом.

Заборонено: переносити реальні PII в стейдж/аналітику без анонімізації; ділитися з вендорами поза договором.

5) Етичні комунікації в інцидентах

Правдивість і своєчасність: ETA статусів, чітка мова, відсутність замовчувань.
Не звинувачувати окремих людей: фокус на фактах і системних причинах.
Ніяких «тихих» виправлень: зміни, що впливають на користувача, потрібно позначати.
Обмеження спекуляцій: "Ми перевіряємо X, наступне зведення в 20:15».

What is happening/who is affected/what we are doing/when the next update/where to follow

6) Етика автоматизації та ШІ в операціях

Чіткий периметр: список дій, які АІ/бот може робити без підтвердження (тільки оборотні і низькоризикові).
Explainability: до кожної рекомендації - джерела та аргументи, заборона «без посилань».
HITL (людина в контурі): підтвердження чутливих дій (перекладка трафіку, перемикання PSP, зміна лімітів).
Аудит: журнал промптів/дій/рішень, dry-run звіти.
Bias & fairness: регулярна перевірка рекомендацій на перекоси (гео, пристрої, тип гравця).
Дані для АІ: заборона на «підсмоктування» PII/секретів; використання знеособлених вітрин.

7) Взаємовідносини з вендорами і конфлікт інтересів

SLA/OLA мовою SLO: чесна карта залежностей; публічні факти по аутейджам вендора.
Конкуруючі інтереси: не приймати архітектурні рішення через «особисті бонуси/реферальні схеми».
Етика тендерів і пілотів: порівнянні тести, документовані критерії перемоги.
Заборонено: приховувати провайдерські збої як «наші», змінювати метрики порівняння «під переможця».

8) «Червоні лінії» (непересічні)

Маніпуляції даними та звітами.
Приховування інцидентів, що впливають на користувачів/гроші.
Використання реальних PII в незахищених середовищах.
Автоматизація незворотних дій без HITL і rollback-плану.
Тиск на співробітників з метою «прикрасити» метрики або пропустити гейт.

Порушення - тригер для формального розслідування, аж до зупинки релізів.

9) Політики і норми (фрагменти)

- All metrics are described in the catalog with formula, window and owner.
- Formula change - via RFC and parallel run (old vs new).
- Any exceptions in the SLA are documented and signed by the parties.

- First summary of 15 minutes, then ETA.
- Tone: facts, hypotheses are marked, references to artifacts.
- It is forbidden to promise deadlines without justification (progress/plan/resources).

- Allowed: summaries, tickets, requests for observability, annotations, pre-scale (reversibly).
- Requires confirmation: feilover, changing limits, enabling safe-mode, canary pause.
- Required: activity log, explainability, dry-run before use.

10) Ролі та відповідальність

Head of Ops: власник етичних політик, авторитет «стоп-крана».
Інцидент-менеджер: якість і чесність комунікацій, контроль постмортемів.
SRE/Observability: SSOT метрик, аудит формул і алертів, захист від «косметики».
DPO/Безпека: приватність, доступи, розслідування витоків.
Legal/PR: відповідність законам/договорам, зовнішні комунікації.
Команди доменів: дотримання гейтів, коректні дані та артефакти.

11) Дашборди і артефакти етики

Metrics Integrity: розбіжності Online↔DWH, зміни формул, застарілі панелі.
Incident Comms: час до першого апдейту, дотримання ETA, повнота зведень.
Privacy & Access: звернення до PII, аномальні запити, терміни retention.
AI Governance: кількість автодій, частка dry-run, відкати, спірні рішення.
Vendor Truth: інциденти по провайдерам, зіставлення їх звітів і наших SLO.

12) Чек-листи

• Є фічефлаги і план відкату.
• Включені SLO-алерти та анотації.
• Немає тиску «зверху» на обхід гейтів.
• Ризики/виключення задокументовані, узгоджені.

• Своєчасний перший апдейт і ETA.
• Факти відокремлені від гіпотез, посилання на дані.
• Немає спроб занижувати масштаб/вплив.
• Постмортем в термін, дії призначені.

• Перелік дозволених автодій затверджено.
• Включений журнал і explainability.
• PII не використовується/замасковано.
• HITL для чутливих операцій.

13) KPI зрілості етики

Metrics Integrity Score (дрейф Online↔DWH ≤ 2%, частка версіонованих формул ≥ 95%).
Incident Comms SLA (перше зведення ≤ 15 хв, дотримання ETA ≥ 90%).
Privacy Violations = 0, частка доступів до PII з виправданням = 100%.
AI Safety: частка оборотних автомобілів = 100%, відкати <5%, спірні кейси розібрані = 100%.
Whistle Safety Index: анонімні канали працюють, звернення розбираються ≤ 7 днів.

14) Анти-патерни

«Фарбуємо траву»: косметика в метриках, перевизначення SLA «заднім числом».
«Нічні релізи без прапорів» заради дедлайнів.
Приватні чати і рішення без журналювання.
Токсичні ретро/постмортеми, пошук винних.
АІ без RAG/пояснюваності, «чорний ящик» в операціях.
Надлишковий збір даних «про всяк випадок».

15) Практичні формулювання (можна копіювати в політику)

We tell the truth about the state of the systems.
We do not hide incidents and do not distort metrics.
We protect user data and restrict access.
We automate only reversible and safe actions, the rest is through HITL.
We document decisions and respect the "stop crane."

- SLO/guard rails are active; rollback plan checked.
- Changes of metrics/formulas are formalized by RFC and announced.
- No conflicts of interest, decisions made on data.

16) 30/60/90 - план впровадження

• Затвердити «червоні лінії», кодекс, політику інцидент-комунікацій і приватності.
• Призначити власників (Head of Ops, DPO, Observability).
• Запустити панелі Metrics Integrity та Incident Comms.

• Впровадити RFC для формул метрик і SSOT; Переглянути спірні панелі.
• Формалізувати периметр ШІ/ботів (дозволені дії, HITL, журнал).
• Провести тренінг з етики для он-колла та керівників доменів.

• Провести аудит дотримання, розібрати кейси/скарги, оновити політики.
• Зв'язати KPI етики з OKR команд (наприклад, Incident Comms SLA, Integrity Score).
• Провести ретро по ефективності і коригування «червоних ліній».

17) FAQ

Q: Що робити, якщо бізнес просить «підкрутити» SLA звіт?
A: Відмовити, пославшись на політику чесних метрик і SSOT. Запропонувати альтернативу: метрика «досвід користувача» зі зрозумілими винятками, оформленими через договір.

Q: Як поєднати швидкість релізів і етику?
A: Малі інкременти, фічефлаги, канарки та автогейти по SLO. Етика - не гальмо, а страховка від дорогих помилок.

Q: Коли публічно визнавати помилку?
A: Завжди, коли вплив відчутно для користувачів/партнерів. Шаблон статусу + план дій + терміни.