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

[baiwfg2]

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

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

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

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

[pushback]

你真是开发？

[baiwfg2]

当然，开发这边确实有可能因为人力不足，deadline 期限等原因，将就上线，这不是开发 的问题，管理问题

[mhycy]

如果投入的钱足够多，平台足够稳定可靠，那么被叫起来的就是开发了

[zhilincom]

告警不是应该直接电话打到对应开发的手机上吗？要区分是什么告警，对应的负责人都分配好。

[HansLee]

当然学学我亚麻巨硬谁开发谁 oncall 啊，开发被叫起来的多了就会去思考业务之余，怎么提高系统稳定性了

[rrfeng]

SRE 了解一下

[index90]

我比较好奇为什么致命告警总是半夜两三点爆发，而早上的却很少听说？
半夜两三点流量特别大？早上却很小？

[ly4572615]

有很多手段可以不用接电话，但是一个不小心就是成本翻倍

[Ariver]

devops.

[baiwfg2]

@Ariver 我赞同开发实现的，开发来负责。但是开发为了避免被叫起，还是需像 @HansLee 说的，不断磨炼改善系统稳定性对吧

[murmur]

运维有值夜班的，这是他们的工作，不用开发操心

[barrysn]

@index90 了解一下业务变更
@baiwfg2 如果开发真能让开发的程序质量有保证，运维会轻松很多

[index90]

@barrysn 所以答案不是很明显么？业务变更没有规范或不遵守规范

[anjing01]

三更半夜运维接告警有几种：
1 、硬件告警，如内存错误 /Raid 降级类，这种基本上通过冗余等方式解决
2 、外企，服务对象是国外客户有时差，这个以前是叫应用运维，现在是叫 SRE/DEVOPS 解决，项目详细的抛错代码及对应解决方案 wiki，监控是全流程的埋点，可以很快定位是哪里有压力或者瓶颈。至于打印堆栈 /dump 内存这种看贵司花多少钱招运维把，5000 的运维肯定是干不了的；
3 、晚上定时任务类的，大数据处理类的，这种基本放到凌晨跑，出了故障也比较常见，基本上运维可以解决。

[barrysn]

@index90 问题很多，业务变更可能是开发问题， 也可能是运维问题，也可能是流程问题，也有可能是资金问题等等
并不能确定是哪里的问题，
其实楼主说经常性看到运维半夜处理紧急问题，这个应该说明 公司内部肯定是有问题的，但一直没有处理或者没有更好的处理办法，
业务变更是我猜的，还有可能是跨境业务

[U97F3]

你们没测试？

[cmdOptionKana]

这让我联想到餐厅清洁工的怨言。

以前我听到过餐厅清洁工埋怨客人把地方弄得太脏，导致她们工作很辛苦。

但是这里有个悖论：如果客人素质都非常高，不仅不会不小心把东西弄到地上，甚至多数人还会自觉收拾桌面，那么，结果就是餐厅会减少清洁工的数量。

比如宜家餐厅提倡客人自己收拾，他们就可以招聘更少的清洁工，降低成本。但这对清洁工来说是坏消息啊……

[heyjei]

还有夜间批处理业务，数据必须在第二天上班前准备好的。

[heyhumor]

辛苦钱辛苦钱，没有辛苦没有钱。别瞎操心了

[dswyzx]

@index90 白天一万个错误也无所谓,因为人都在在上班.晚上一个 error 很可能导致叫起来一堆人.然后印象深刻.