KTLO 是 “Keep The Lights On” 的首字母缩写，字面意思是”保持灯亮着”。在 IT 和研发语境里，通常翻译为**“维持日常运转”或”基础维护工作”**。
当你在后台代码统计中看到一部分工作被归类为 KTLO，它指的是为了保持现有系统或产品正常、稳定运行而必须进行的日常维护性工作。这部分工作与开发”全新功能（New Features）“或”创新性项目”是相对的。
KTLO 通常包含哪些类型的工作？
- Bug 修复： 解决现有系统中出现的问题或故障。
- 依赖更新与安全补丁： 升级第三方框架、库，修补已知的安全漏洞。
- 日常运维（Ops/DevOps）： 服务器维护、日志清理、监控报警响应等。
- 清理技术债务与代码重构： 优化现有代码结构，使其更易于维护，而不是为了增加新功能。
- 合规性调整： 为了满足新的法律法规或平台规则（如 API 接口变更）而做的被动修改。
为什么要单独统计 KTLO？
工程团队单独统计 KTLO，核心是为了衡量团队的精力投入和系统的健康度。
- 衡量精力分配： 如果一个团队的 KTLO 比例过高（例如达到 60% 甚至 80%），意味着团队大部分时间都在”救火”或维护老旧系统，根本抽不出精力去开发能带来新业务增长的功能。
- 评估技术债务： 如果 KTLO 占比随着时间推移不断上升，往往是危险信号——系统的技术债务越来越重，代码越来越难以维护。
- 资源规划： 理想状态下，技术管理者希望通过重构、自动化测试和 CI/CD 流程，把 KTLO 的比例压缩并稳定在一个健康范围（例如 20% - 30%），把剩下的精力全部投入到创造新价值上。
说白了，统计中的 KTLO 就是在告诉你：团队花了多少精力，仅仅是为了让现有的代码继续跑下去。