本站于2023年9月4日。收到“大连君*****咨询有限公司”通知
说我们IIS7站长博客，有一篇博文用了他们的图片。
要求我们给他们一张图片6000元。要不然法院告我们

为避免不必要的麻烦，IIS7站长博客，全站内容图片下架、并积极应诉
博文内容全部不再显示，请需要相关资讯的站长朋友到必应搜索。谢谢！

另祝：版权碰瓷诈骗团伙，早日弃暗投明。

相关新闻：借版权之名、行诈骗之实，周某因犯诈骗罪被判处有期徒刑十一年六个月

叹！百花齐放的时代,渐行渐远!

---

互联网，讲究快速迭代，快速上线，敏捷开发。

有些固定上线时间的项目，可能因为技术方案变化，导致测试时间压缩，最终上线出了问题，有些锅，却由有苦说不出的运维来背了。

运维苦，今天，运维有很多心里话想和研发哥哥与测试姐姐说一说：

（1）“敏捷开发，频繁交付”的KPI，真不是增加运维人手就能解决的，需要自动化回归的支持，需要自动化上线的支持；

（2）“上线失败，快速回滚”的KPI，真不是增加运维人手就能解决的，需要回滚方案的支持，而回滚方案真的测试过么；

（3）“快速扩容，快速响应”的KPI，真不是增加运维人手就能解决的，需要架构设计的支持（很多系统无法水平扩展，来了机器，无法扩容），需要快速部署的支持，需要服务发现的支持（所有上游修改配置重启肯定是不行的），需要压力测试和容量评估的支持；

（4）“系统高可用”的KPI，真不是增加运维人手就能解决的，需要优雅降级的支持，需要架构设计的支持，如何评判系统是否高可用？这个简单，关掉线上任何一台机器试试，看用户服务是否受影响，如果受影响，研发哥哥们拜托了；

（5）“快速故障报警”的KPI，真不是增加运维人手就能解决的，需要监控系统的支持（操作系统和运维层面的监控，我们可以实施，但错误日志、接口、业务的监控呢？），另外报警短信能少一点么，过度报警会让人变得“麻木不仁”的；

（6）“快速故障定位”的KPI，真不是增加运维人手就能解决的，需要数据量化健康信息的支持，需要快速诊断的支持；

画外音：到家集团的守望者平台，以及调用链跟踪系统，还是很好用的。

（7）“快速故障恢复”的KPI，真不是增加运维人手就能解决的，需要故障转移的支持，相信我们，故障发生时，如果运维人员不知道怎么抉择，且又必须做出抉择，这时的抉择往往是错的（我们能做的，是重启），我们也不想凌晨打给你们，但希望你们能实现自动化方案；

（8）“内审合规”的KPI，真不是增加运维人手就能解决的，在资源允许的情况下，请不要手动删除任何资源，数据是很重要的资源。访问控制和权限申请的流程，真的不是限制大家，相反，哪一次数据的误删除，不是我们加班来恢复的？宝宝心里苦呀；

我们的KPI都掌握在大家的手里，自己人不为难自己人，希望研发哥哥与测试姐姐理解。

技术本一家，既然相爱，何必相杀。

————————————————

文章来源：CSDN博客

原文链接：https://blog.csdn.net/shenjian58/article/details/104284663

如有侵权，请联系删除