Качество на доставката

Отчетен период: юни 2026 г.

Честота на релийсите в продукция 21
Медиана на времето за доставка на промяна 7
Дял на счупените релийси 14.3%
Дефекти след релийс в продукция 5.81
Дял на релийсите, доставени навреме 89.7%

Честота на релийсите в продукция

Отчетен период: юни 2026 г.

По администрация

По услуга

Медиана на времето за доставка на промяна

Отчетен период: юни 2026 г.

Брой промени по администрация

Дял на счупените релийси

Отчетен период: юни 2026 г.

По администрация

По услуга

Дефекти след релийс в продукция

Отчетен период: юни 2026 г.

Дефекти/релийс по администрация

Дял на релийсите, доставени навреме

Отчетен период: юни 2026 г.

По администрация

По услуга

Методика, допускания и качество на данните

Обхват

Юни 2026 г.; всички 51 релийса са с дата на деплой през юни. Перспектива 1 (ал.5, т.1) по рамката DORA, по модела на обектите A (релийс), B (промяна), C (дефект).

Знаменатели = ПРОДУКЦИЯ 

По спецификацията: Change Fail Rate = A-prod с намеса ÷ всички A-prod; Дефекти/релийс = C ÷ A-prod. Това коригира по-ранния избор „всички среди“ (стойностите за всички среди са дадени за сравнение). 

Deployment Frequency

Брой прод. релийси/месец, вкл. hotfix (всички статуси са succeeded; няма failed/rolled-back). Без hotfix = 18. 

Change Lead Time

Медиана на (deploy − start). За 42 от 61 промени без валидна връзка се приписва домашен прод. релийс по дати (най-ранния прод. релийс с deploy ≥ start; предпочитание администрация+услуга). Медиана = 7 дни. 

Тежест на дефектите 

„critical и сериозни“ = severity ∈ {critical, major}. В v2 severities са рецензирани: 131 записа с предишен заместител „from a fixed list“ вече са Major (общо major=141). „high“ (7) не се броят. 

Дедуп на дефекти 

defect_id е ненадежден (заместители като „email“ се повтарят), затова НЕ се ползва като ключ; премахнати са само 1 напълно идентични реда. Реалните дефекти не се сливат.  

Дедуп на дефекти

defect_id е ненадежден (заместители като „email“ се повтарят), затова НЕ се ползва като ключ; премахнати са само 1 напълно идентични реда. Реалните дефекти не се сливат.

On-time — ограничение

Знаменателят обхваща само реализирани планирани релийси; планираните, които не са пуснати, липсват в лога и не могат да се възстановят от него. Нужен е отделен feed с проектния план. 

Дати

Смесени формати (03.06.2026, 2.6.2026, 24/06/2026, 23.6.2026 17:20). Единен разбор „ден-първи“ с резервен „месец-първи“; всички сериозни прод. дефекти попадат в юни при всяка от интерпретациите.

Разрешено в v2 / оставащо

Разрешено в v2: severities рецензирани (без „from a fixed list“); environment_found попълнено (0 празни); needed_post_release_fix нормализирано (0→no). Оставащо: Changes.release_id не съвпада с Releases в повечето редове (35/61 без връзка) → Lead Time чрез приписване по дати; Releases.release_id с нехомогенна схема; заглавие „release_id “ с краен интервал. 

Съответствие

Публикуват се само агрегати. Преди първо публикуване по ЗЕУ: правен/ДЗЛ преглед; сигурностните показатели — отделно (раздел 5 на приложението).

Възпроизводимост 

compute_kpis_v2data.py от KPI Framework SI v2.xlsx → CSV + този workbook. Всички проценти/отношения са Excel формули (нула грешки при преизчисление).