运维责任

Dynatrace KiroCrew app：Dynatrace 问题的看板式分诊控制台

dynatrace-oss/dynatrace-kirocrew-app

这是 Dynatrace 的看板式控制塔应用，提供只读视图，按生命周期泳道（New、Ongoing、Under maintenance、Recently closed）对 problems 进行分诊，并按健康状态（Unhealthy、Watch、Healthy）分组展示 services 和 applications。默认的 Smart 排序由 KiroCrew agent（dynatrace-smart-rank cron，每 15 分钟运行）根据类别权重、影响范围、根因存在性、持续时间、复发情况以及环境记忆对活跃问题卡片按分诊紧急度排序，并在卡片上展示排名与一行理由；同时也提供按严重程度、最新、影响最多、运行最久等确定性排序。应用本身只读，不会关闭问题或改变 Dynatrace 状态，需要执行的动作会跳转到 Dynatrace 或交给 KiroCrew agent。

云降低了运维复杂度，但许多团队需要有人来完全负责这件事

这篇文章讨论的是：当工程团队人手精简、却要运行多个生产应用时，凌晨三点出故障才是真正考验运维责任归属的时刻。问题在于，很多团队里的开发者既要写功能又要值班，答故障的人却不了解系统阈值和自愈逻辑，被迫在半夜替系统做决定。文章主张，好的平台应在部署时就定好“健康长什么样、异常怎么办、如何通报”，而不是等事故来了才临时判断。它还指出，这类团队往往卡在管理第三个应用时，需要能同时接纳旧式 Java、.NET、Python 和容器应用的统一管理方式，从而少招人、多交付产品。