如何运维一个日趋复杂的大型分布式计算系统

1,系统管理员模式(开发部Dev和运维部Ops)
研发部门:随时 随地发布新功能,没有任何阻拦。
运维部门:一旦一个东西在生产环境中正常工作了,就不要再进行任何改动。
由于两个部门使用的语境不同,对风险的定义也不一致。在现实生活中,公司内部这两股力量只能用最传统的政治斗争方式来保障各自的利益。运维团队宣称:任何变更上线前必须经过由运维团队制定的流程,这有助于避免事故的发生。开发团队吃过苦头之后,宣称他们不再进行大规模的程序更新,而是逐渐转为功能开关调整,增量更新,以及补丁化。

2,Google的解决之道:SRE(Site Reliability Engineer)
SRE就是让软件工程师来设计一个新型运维团队的结果。SRE有两类工程师:
第一类,团队中50-60%是标准的软件工程师;
第二类,40-50%则是一些基本满足Google软件工程是标准,但是同时具有一定程度其他技术能力的工程师。
SRE团队成员具有如下特点:
(1)对重复性,手工性的操作有天然的排斥感。
(2)有足够的技术能力快速开发出软件系统以替代手工操作。
Google为整个SRE团队所做的所有传统运维工作设立了一个50%的上限值。传统运维工作包括:工单处理,手工操作等。另外50%的精力花在真实的开发工作上。

3,SRE方法论
SRE团队要承担一下几类职责:
可用性改进,延迟优化,性能优化,效率优化,变更管理,监控,紧急事务处理以及容量规划与管理。
1)确保长期关注研发工作。SRE处理运维工作的一项准则是:在每8-12小时的on-call轮值期间最多只处理两个紧急事件。
2)在保障服务SLO的前提下最大化迭代速度。可靠性目标:
基于用户的使用习惯,服务可靠性要达到什么程度用户才会满意。
如果这项服务的可靠程度不够,用户是否有其他替代选择。
服务的可靠程度是否会影响用户对这项服务的使用模式。

4,监控系统
监控系统是SRE团队监控服务质量和可用性的一个主要手段。监控系统不应该依赖人来分析警报信息,而是应该由系统自动分析,仅当需要用户执行某种操作时,才需要通知用户。
一个监控系统应该只有三类输出:
a)紧急警报;用户需要立即执行某种操作。
b)工单:意味着接收工单的用户应该执行某种操作,但是并非立即执行。
c)日志:以备调试和事后分析时使用。

5,应急事件处理
评价一个团队将系统恢复到正常情况的最有效指标,就是平均恢复时间。
Google SRE将大部分工作重心放在”运维手册“的维护上。

6,变更管理
SRE的经验告诉我们,大概70%的生成事故由某种部署的变更而触发。变更管理的最佳实践是使用自动化来完成以下几个项目:
1)采用渐进式发布机制
2)迅速而准确地检测到问题的发生
3)当出现问题时,安全迅速地回退改动

7,需求预测和容量规划
需求预测和容量规划简单来说就是保障一个业务有足够的容量和冗余度去服务预测中的未来需求。
自然增长:用户使用量上升,资源用量上升
非自然增长:新功能的发布,商业推广,以及其他商业因素在内
容量规划几个步骤:
1)必须有一个准确的自然增长需求预测模型,需求预测的时间应该超过资源获取的时间。
2)规划中必须有准确的非自然增长的需求来源统计
3)必须有周期性压力测试,以便准确地将系统原始资源信息与业务容量对应起来。

8,资源部署
资源部署是变更管理与容量规划的结合物。新资源的部署与配置是一个相对比较危险的操作,必须要小心谨慎地执行。

9,效率与性能
一个业务总体资源的使用情况由以下几个因素驱动的:
用户需求,可用容量和软件的资源使用效率。

=============================

灰度发布
灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式。在其上可以进行A/B testing,即让一部分用户继续用产品特性A,一部分用户开始用产品特性B,如果用户对B没有什么反对意见,那么逐渐扩大范围,把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现,调整问题,以保证其影响度。

冗余度
冗余度在数据传输中,由于衰减或干扰会使数据代码发生突变,此时就要提高数据代码的抗干扰能力,使相应数据具有一定的冗余度。冗余度,通俗的讲就是数据的重复度。

====================

什么是高级运维?

传统的系统监控能力+新生代运维套件能力,形成能够应对云场景和多元化融合场景的电信软件业务下一代高级运维平台。

系统监控能力:运维操作界面,告警上报,性能统计,资源管理,安全管理。
运维套件能力:监控分析,健康检查,故障定界定位,故障自愈。

高级运维构筑海量,自动化,智能化,开放聚合的融合运维解决方案,为客户提供极致体验并最终实现无人值守的目标。
高效监控,智能分析,主动保障,高性能&大容量。

关键特性:
监控分析:系统监控(设备管理,资源视图,告警管理,性能监控),容量管理,健康度分析。
业务保障:服务调用链,业务拨测,日志服务,故障信息收集,服务跟踪,安全监控,作业控制台。

=====================

云计算的三种服务模式:IaaS,PaaS,SaaS。
http://blog.csdn.net/hjxgood/article/details/18363789

=====================

我当时所在的项目组是后台的操作维护平台,主要负责单板的加载,告警管理,话单管理等。
开发和维护工作量各占50%,当时做过两个比较重要的特性:
1,base平面解藕;(解藕绑定在不同网口上面的IP,满足负载均衡的需求)
2,故障诊断系统;(针对呼叫的接入流程,展示呼叫信号的全程跟踪图,然后给出现问题的节点标红并告警)

发表评论

电子邮件地址不会被公开。 必填项已用*标注