2019-12-24老师，突然有个问题好奇的问一下，你们公司的开发和测试环境，与生产环境是同一个组负责的吗？我们公司有专门的Unix团队和OPS团队负责生产环境上的发布，我们这个部门专门负责开发和测试环境的自动化，我们的工作就是给生产发布提供测试过的包。说实话我还是很喜欢我现在这个岗位的职责，因为不是生产环境，所以不需要值夜班。好奇这样的岗位会不会普遍？你们公司是不是也有这样的岗位？作者回复: 恩，你说的这种情况还是非常普遍的，无论是部门职能划分的缘故，还是类似金融保险的监管要求。对于互联网公司来说，其实没有这么清晰的边界，像我们这边首先无论你是什么环境，部署的平台和工具都是同一套，当然自建的集群除外。然后无论是部署测试，预发，生产都是研发自己来做，运维不负责应用的发布工作，上线有一定的流程要求，所以这块并没有实现完全的自动化。不过运维该值班还是要的哈，纯无人值守还是有点理想。
2
2019-12-24提到删库且注意到没备份的事情其实不只老师所说的有，我同样听过类似的案例。相关信息不能透露不过确实真实发生过，不过可能由于DBA确实是业界的资深人士且及时处理后果被控制到最小化且几乎没啥影响。
案例简述：某天1测试数据库被删，同行反馈；该公司DBA立刻检查，不过排查过程中发现不仅权限不对且之前生产做的备份报警策略未生效，不仅测试数据库被删且多日数据库其实一直备份失败；立刻权利回收且修改备份报警策略。究其问题其实是开发和运维同时犯错了，所幸DBA够资深且检查够细致避免了可能的灾难性事故的发生。由于各方都有责任，内部相互预警处理的。
国内外的文化差异就是：问题是否直接公开，其实gitlab的处理方式应当算是一次极其成功的危机公关。前段时间ES被爆出安全漏洞就没有这种魄力去处理危机，采取了和国内类似的藏。问题并不可怕，可怕的如何合理处理好问题，这其实涉及到的属于PM的课程。
DevOps所要求的能力其实不是表面上的：真实想做好确实需要很全面的软件层能力和处理事情的能力，老师分享的同时算是补了个国内的案例。谢谢老师今天的分享，这事儿真正做好不容易。展开作者回复: 悄悄的说，这种事情我在国内某大行也遇到过，幸好是发现了这个问题，没有导致严重的问题，但是这也给我们提了个醒，越是觉得没有问题的地方，就越应该花时间精力去看。所以最近我们也在安排年末的演练，这次的不同之出在于，不仅仅是安排一个任务下去，有人执行并给出执行结果，而是要把恢复过程内部直播，并让更多的人来挑战你，这样才能把事情做到位哈！
2
2019-12-24案例很有启发，细节公开，处理步骤都公开确实不好做到，但是这种方式对公司对个人的成长有极其重要的推动。作者回复: 其实就像当你知道你的代码会被人Review的时候，你自然会多想想怎么能写的好一些一样，很多时候不公开不透明，就是因为做的烂，真有多少技术含量倒也未必。