开发能在多大程度上帮助运维减轻半夜被叫起的负担？

[baiwfg2]

我司我组的运维都看着挺辛苦的，经常半夜两三点起来处理故障问题，因为经常有致命告警。他们往往对某些实现上的细节不清楚，所以也很有可能把主导项目的开发 leader 叫起来，于是大家都在深更半夜不太清醒的状态下处理故障。

我一直在想，如果开发把功能做得完备些，特别是在上线前多测试演练，多在可能故障的地方埋点以帮助在意外情况下可以恢复到 一个慢但准确的 Plan B 的执行路径上来，这样哪怕半夜被叫醒，也可以快速迁到 plan B，不至于人为操作半天，毕竟人不在清醒情况下更容易出问题。

所以我总觉得运维如此辛苦，是开发
1 ）没有用心把系统做得故障冗余
2 ）没有重视上线前测试演练
3 ）没有配合和敦促运维一起做好面板监控和自动化处理（于是乎总要通过慢的命令行的人工操作）

的结果。（我自己是开发 ，所以也会审视我们的开发队伍）。大家觉得呢

[tabris17]

你让运维无事可做他们才会恨你

[passerbytiny]

从经常半夜两三点发生致命告警，到经常半夜两三点不太清醒的状态下处理故障，再到经常半夜两三点发生致命告警——胳膊要有胳膊的觉悟，你是扭不过大脑的。

这种情况，要么是领导层已经烂掉了，要么是领导层权衡过后认为现状就行。但不管哪种情况，作为小开发，该管的事是“提出问题”，而不是“怎么解决问题”。

[ww2000e]

反了，开发是要确保告警稳定有效，能给运维喊醒。。

[coderluan]

开发做的更好 -> 运维减轻负担 -> 部分运维被"优化" -> 给开发涨工资.

楼主老千层饼了(狗头).

[fueen]

你心疼运维，谁来心态开发呢？

[Jooooooooo]

除去通常的评审, review, 测试等等环节, 上线变更一定做好:

1. 可灰度. 尽量可灰度, 能用线上小流量验证, 出现问题影响范围也可控. 慢慢扩量.
2. 可回滚. 尽量可快速回滚 (比如一键的配置开关), 一旦出现问题立马退回上线前一模一样的代码, 防止大面积故障长时间得不到处理.
3. 可监控. 尽量上线的内容是可以通过某种监控指标等确认是正常的. 一般是确认业务正常 (比如上报业务指标等), 如果会影响性能还需要确认系统正常 (比如监控上线前后的 cpu 等等)

严格做到这三点, 能规避不少问题.

[firefox12]

从设计上就要解决了， 应用出现故障 可以降级吗？ 可以加节点完成吗？ 有自助的解决方案吗？ 有完善的监控帮助观察吗？ 有足够多的业务监控 帮助定位问题吗？

设计师的水平就没达到，不靠人力靠什么？ 设计师的水平达到了，那么就砍人啊，需要那么多人干什么？

[Amance]

减轻负担要运维干什么

[pangleon]

@anjing01 还有一种就是真的是业务在凌晨， 比如配送物流

[Songxwn]

运维狗表示，有这么为运维着想的开发表示欣慰。

[yuanbo6]

昨晚上十二点四十被电话叫醒救火的路过。
本人非开发，算是实施交付的小 leader，成天和我们的研发商务技术等等部门打交道。
目前不处理一线问题了，处理二线问题多一些。

我觉得项目碰上半夜救火这种事情很多方面的因素都有，
1.比如我程序极限承载能力是 10W 并发，集群承载能到 20W，但是客户拿去招投标就说 20W，结果实施方案计划并没有涉及集群部署这样，这是方案留下的隐患问题。当然也存在商业沟通的问题。
2.比如程序设定的功能 A 很好但是 A 不符合用户实际使用需求，用户提了个 A+的功能，然后单纯的为了那个+去做定制开发，为了定制而定制，定制开发这种事容易出问题我就不多说了……我们后面可能发现 A+确实更贴合实际需求，但是下一个版本乃至大版本更新都没有把 A+纳入基线开发，还只推出 A 功能，就还会重复做 A+开发，怕研发兄弟们工作量不饱和吗？……这算是产品规划方面的问题
3.在开发过程中吧，确实很多情况现场生产环境和开发环境不一样（成天听研发大兄弟和我诉苦），尤其是一个产品分了很多模块，每个模块又特别细化到单个小组为单位进行开发，可能真就是自己测试自己的那些功能性能啥问题都没有，然后一到现场，这个接口不对，那个字段不对……内部沟通也有些问题
4……一时间想不到了。不说了我去补觉了，三点多才睡。

世界上没有完美的程序，也没有完美的产品，也没有完美的人。产品、研发、交付、运维、商务……都不容易。

[yuanbo6]

@yuanbo6 思绪略乱，各位看官凑合看看就行

[airplayxcom]

开发都把雷排完了 要运维干嘛？

[airplayxcom]

我司运维天天在那儿嗑瓜子闲聊呢

[beidounanxizi]

这是老板对公司技术人才不重视的原因，
你们估计没有 devops 吧，
这种问题不应该是直接告警通知到部门负责人啊 还需要运维 夜里爬起来干活 🐶

[nnd]

楼上一个个狗开发，能不能做个人啊？自己辣鸡菜，还美其名曰给运维找工作，不让运维别优化。 按你这样讲，需求每天变更一次的产品需求，每周重写一份 PRD，才是给你找工作，避免别优化的最好手段。 运维不用你找工作，我们有自己的工作，不了解请闭嘴。总是感觉自己比别人能力强，比别人聪明，这是病，赶紧治。

[nnd]

@nnd #36 如果一个运维只能天天嗑瓜子闲聊，这是对自己不负责，对公司不负责。不过运维天天嗑瓜子的闲聊的公司，也不是什么厉害的公司。这样的运维，这样的公司对社会对没有太大帮助，建议一起优化掉，提高社会效率

[tolerance]

开发是应该尽可能列出可能出现的异常情况，并告知运维如何处理，让运维能够对应状况处理，而不是出现问题就把开发叫来现场分析问题。

[freelancher]

想到我以前上班的游戏公司。基本上游戏运行中没自己挂掉过。偶尔一次二次，特别少。我们运维自己硬件和系统和应用层面都顾得好好的。工作起来那叫一个轻松。

可惜老板做死，把公司弄黄了。现在都找不到这么靠谱的开发团队了。

[pmispig]

具体要看是什么问题吧，能不能举点例子