因为现在它根本不能用来灭火
专业性扭曲：工作如何塑造不良习惯
我之前说过，在IT行业，每天上百次的切换中，决定工作方式的不是家庭习惯，反而是工作本身塑造了我们“立即解决问题”的倾向，常常缺乏对后果的充分分析。
我为您找了一些例子，说明人们如何被“即时满足”的诱惑所俘获——比如冲动购物。可怜的人们在下单时，以为“一键购买”就是解决问题的唯一步骤。
那是谁干的？想象一下，大型公司的CTO和产品经理也是如此。他们向DevOps团队“订购”快速解决方案。当他们终于收到装有最新技术（Apache Kafka、对象存储S3、分片数据库、语义搜索）的“盒子”时，却并未发现一个令人不快的事实：这些技术没有附带安装、配置和使用说明。没有部署脚本，也没有可扩展性、性能监控能力。最重要的是，没有人提前告知DevOps团队这些技术将被实际部署。
从订购之日起三个月过去，本应带来解脱的期待却变成了新的麻烦。领导者只能用这样的话来表达自己的失望：“盒子到了……但三个月后才想起来，当初为什么要买它。” 对快速胜利的追求最终演变为运营混乱，而缺乏战略规划则让技术变成了无穷无尽的麻烦来源。## 我们下一个版本需要 Kafka
有位技术负责人读了 Habr 上一篇关于“实时事件流”的文章，点头表示：“我们需要 Kafka。”——没有征求建议，没有架构评审，也没有 DevOps 的参与。熟悉这种场景吗？
是的，Kafka 是开源的，是的，它可扩展。但请随便问任何一个实际在集群中使用过 Kafka 的团队：Kafka 的成熟度并非线性增长，而是一个阶梯函数。
- 0–6 个月：“一切正常！”——分区隐性失衡、Broker 负载不均、不可控延迟
- 6–12 个月：“为什么延迟在增加？”——手动重新分配、灭火式处理、责任碎片化
- 12+ 个月：“谁负责这个？我们怎么关掉它？”——“僵尸进程”现象，外部支持成本未被计入
没有 DevOps 就绪的自动化、可观测性和全生命周期管理，Kafka 不会给你数据流，只会给你 Telegram 上不断推送的告警。## S3兼容存储？很好。现在请保护它
Ozon团队花费数月时间将Lusca重构为S3兼容存储——并非因为S3本身复杂，而是因为要在事件驱动架构上实现强一致性、管理数据库后台进程以及恢复TB级数据，这些任务需要深厚的专业知识和大量时间。
更糟糕的是：如果您在没有DevSecOps规范的容器环境中部署它——没有镜像扫描、没有密钥管理、没有L7网络策略——您不会获得一个存储系统，而只会制造一个安全漏洞和技术债务。纵火。
数据库分片：不可回头的一步
只有在耗尽垂直扩展、查询优化、缓存层级和读取副本之后，才进行分片。这是最后的手段。
如果分片操作执行不当，我们将得到“热点”分片、复制延迟和跨分片查询故障。尤其是当分片键选择不当的时候。 如果没有 DevOps 工具支持备份、监控和重新分配——我们将用可用性换取可扩展性。
关键在于，我们无法“反分片”。一旦实施了这种方案，就无法轻易撤回，否则将付出数倍的痛苦代价。
现在真正的问题——不是技术问题，而是组织问题
没有任何基准测试会告诉你，现代 DevOps 中最薄弱的环节不是智力资源、内存或操作速度。因为真正的问题在于——由于路线图问题导致的决策延迟。在一些公司中，DevOps路线图根本不存在，甚至有些公司完全没有。这是因为战略被交给了膝上型解决方案的演示销售团队。
反应式执行的文化会导致什么后果？
- CTO签署开发订单后，工程师们没有获得需求规格，而是收到一个“在100台服务器上自动化这个”的指令——没有文档、没有清晰的架构、没有测试覆盖率。
- 三个月后：“为什么这么慢？我们为什么要建这个？”
这不是领导力，这是逃避责任。
在反应式组织中，DevOps团队消耗着宝贵的热情，追逐着日志和图表中的幽灵，修复他们从未设计过的东西，保护他们从未拥有的东西。当事情出错时，责任归咎于人，而非流程。这不是 DevOps，而是“YasnoOps”——“能见者团队”。成熟的 DevOps 文化不追究谁犯了错，而是问：是什么导致了故障？并修复系统，而非寻找责任人。在你们的情况中，系统的问题在于缺乏路线图，以及在决策阶段未纳入 DevOps 的参与。
俄罗斯语境：速度 vs 稳定性
2023-2024 年，俄罗斯 SaaS 市场增长至数万亿卢布，但这并非一个稳定可预测的市场，而是一个“速成锅”。为了显得“现代”，盲目追求速度，反而破坏了真正实现“现代”的基础。我们似乎应该朝着由ГосТех所设定的方向前进。朝统一的日志记录、认证API、监控、符合FSBTEK要求和供应链完整性方向发展。但如何将标准融入那些因匆忙和冲动决策而构建的架构中？如何确保安全，如果DevOps团队并未参与设计？
这样的公司仍把基础设施视为次要问题。 这不是工程上的失败，而是管理预期的失败。
如何改变现状？
解决方案在于转变立场：
- 从“现在就构建它以供销售” → “我们是否准备好在未来可预见的时间内拥有它？”
- 从功能快速交付 → 转向平台的稳定性
- 从DevOps作为“救火队” → 转向DevOps作为“共同架构师”大型企业已经走过这条路。它们公开自己的路线图，为稳定性推迟发布。它们衡量运营就绪度，而不仅仅是发布日期。
它们明白一个简单的真理——没有控制的速度不是敏捷，而是漂移。而在企业级软件中，这种漂移尤其不可接受，因为涉及的是国家机密。
要走出危机，需要转型
- 从反应式管理转向主动规划——制定 DevOps 路线图，早期就让所有利益相关方参与进来。
- 从执行者转变为战略合作伙伴——承认 DevOps 是产品发展不可或缺的一部分。
- 从混乱的实施转向有计划的转型——分阶段引入技术，通过试点和迭代发现差距。
- 那么“购买”按钮就不会再被自动点击了
因为在当今现实中，尤其是在“国技”条件下，忽视运营成熟度不仅是一个风险，而是一个战略错误。