系统管理员模式(二）---google运维连载
系统管理员模式(二）---google运维连载传统的研发团队和运维团队分歧的焦点，主要在软件新版本新配置的变更的发布速度上，研发部门最关注的是如何能够更快的构建和发布新功能，比如谷歌CPC点击广告需要一个新的判断功能，运维部门。更关注的是如何能在他们值班期间避免发生故障，由于绝大数。部分生产故障是由于部署某项变更导致的，不管是部署新版本还是修改配置，甚至有时只是因为改变了用户的某些行为造成负债流量的配比变化而导致故障，这两个部门的目标从本质上来说是相互矛盾的。
极端来说，研发部门想要随时随地发布新功能没有任何阻挡，而运维部门着想，一旦一个东西在生产环境中正常工作了，就不要再进行任何改动，由于两个部门使用的语境不同，对于风险的定义也不一样，在现实生活中，公司内部这两股力量只能用最传统的政治斗争方式来保障各自的利益，运维团队常常宣称，任何变更上线前必须经过有运维团队指定的流程，这有助于避免事故的发生，例如，运维团队会列出一个非常长的检验清单，例数所有以前曾经出现过的生产事故要求研发团队，在上线任何功能之前必须将所有的事故模拟一遍，确保不会重现这个清单，通常没有任何标准，每项事故的可重现程度问题，价值并不一定是一致的，而开发团队吃过苦头之后，也很快找到自己的应对办法，开发团队宣称他们不再进行大规模的程序变更，而是逐渐转为功能开关调整，增量更新以及补丁化，采用这些名词的唯一目的就是为了绕开运维部门设立的各种流程，从而能更快的上行新功能
页:
[1]