|
|
|
|
移动端

1.4.3 基于与业务程序耦合紧密程度的维度划分

《运维前线:一线运维专家的运维方法、技巧与实践》本书共有14位作者,包含了在腾讯、YY语音、UC、京东、盛大游戏、金山西山居、猎豹移动、广发银行、优维科技等多家公司工作的实践经验,基本覆盖了互联网和传统行业运维的各个领域,估计这是迄今为止第一本由这么多资深运维专家联合写成的图书,也是第一本分享了众多一线运维专家亲身实践的图书。本节为大家介绍基于与业务程序耦合紧密程度的维度划分。

作者:云技术社区来源:机械工业出版社|2017-04-22 15:21

年前最后一场技术盛宴 | 1月27日与京东、日志易技术大咖畅聊智能化运维发展趋势!


1.4.3 基于与业务程序耦合紧密程度的维度划分

基于与业务程序耦合紧密程度的维度划分,这点非常重要,这个划分其实是确定系统建设的Owner,从而避免让运维团队承担过多的系统建设职能,否则将会导致运维能力提升缓慢。那么应该如何判断与业务程序耦合的紧密程度呢?我的准则非常简单,线上程序直接调用的就是紧耦合,或者由研发主导的公共服务,类似于API/SDK类的后端服务,应该由测试来主导系统建设;有些服务与程序不是直接关联的,或者是由运维牵头建设的,则由运维来主导,例如LVS、DNS服务等。

有这样一种情况,在很多应用程序中,DNS和LVS服务也存在于程序调用链中,怎么办?在我的方案中,绝对不允许内部服务走DNS和LVS。我们都知道DNS和LVS的服务对于服务异常的处理(DNS无状态、LVS是七层能力弱),远远达不到线上服务的要求,所以要坚决拒绝。如果真的有人要使用DNS和LVS,那么第一告诉他们业务的风险;第二,发生故障的时候,需要让研发参与处理。另外这也是系统的边界没划分清楚的问题,是让运维组件去承担业务上应该具备的容灾容错功能,这会令后面的运维系统建设增加很多不必要的功能。

喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书频道活动讨论群:342347198

【责任编辑:book TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

ASP快速建站全程实录

本书从一个网站制作过程入手,详细介绍基于ASP技术建设网站的全过程。全书共10章。第1章,网站制作规划与流程;第2章,IIS安装与调试;第3...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊