首席架构师白鳝：运维的进阶与哲学之道(2)

1. 以服务目录为工作核心

   什么叫服务目录?很多企业可能连服务目录都不存在,一个IT部门要干什么活,是围绕着服务目录去展开的.哪些最重要,哪些不重要.如果你说任何业务我认为都是最重要的,这确实,但不现实.

2. 以服务级别协议为服务依据

   区别好哪个系统是四个九,哪个系统是五个九.一定要跟业务签订服务级别协议.

3. 以保障业务为工作目标

   不能为了运维而去运维,甚至通过运维去催发出一些新的事,这是不可取的.

4. 以标准化工艺为指导

   标准化工艺是相当重要的.以前我们也经常会碰到,同样一套系统,有多个服务器,里面配置的参数都不一样,这些都是不规范的做法.

5. 以运行基线为判断依据

   随着运维的规模越来越大,场景越来越复杂,我们一定要用一些自动化工具作为辅助手段,光靠人力是愈来愈难满足企业的需求.另外,在进行分析的时候,系统到底健不健康、存不存在问题,要以运行基线作为依据.

6. 以事件跟踪为工作方法

   当出现问题时,通过疑点跟踪,发现有价值的问题.

7. 以闭环管理为考核策略

   任何一个疑点,都必须闭环,这也可以作为管理的一个目标.

不同阶段的运维人员,分析方法、思路是不一样的.

首先,刚入行的,往往会根据现象去分析问题,可是如果碰到一些“超自然”现象就束手无策了.其实不存在诡异的“超自然”现象,任何现象都是有根源的,只是能力认知范围上的不足.

随着能力的提升,我们可以通过抓到系统运营的一些指标、基线去分析问题.但是,光是有指标和基线也仍然不够,假设我们判断一个系统是不是已经达到它的负载极限,是需要根据系统容量来判断的,比如说这个存储能提供多大的IOPS,超过多少额度颜色会上升,运维人对于这些容量指标体系必须有所了解.

另外,如果再往架构师方向发展,就会从整体角度来思考,辩证地看待问题.达到这一地步的话,我们可戏称这人“成精”啦,因为他已经超脱了普通的一种运维范畴.

举几个比较典型的点：

1. 没有绝对的对错.以前DBA圈特别在意对和错的问题,这是不对的,有些网站上就常常有人为了某个处理方法天天打架.但是随着个人能力的提升,对错这个观念可能就越来越淡.
2. 过犹不及.我们总是希望把事情做到最好,讲究“工匠精神”,但实际来说,有时候过了还不如不过.
3. 与过犹不及类似的,最佳方案也许是最坏的.在前些年阿里的Oracle数据库架构中就有个远程维度的问题,当时圈里也做了很多的探讨.就说这个维度会对我的运维带来多大的负担,有没有必要.前段时间我刚好碰到这样一个用户,他也想用这个方案来实现他的性能高可用,但他的使用方法是存在问题的,因为他没有掌握阿里当时使用这个时的精神,简单地去操作这个方案,结果数据库打不开.
4. 眼见不一定为实.即可能有更深层的东西,以前我们碰到的称之为“灵异的问题”,也是因为这里面有你目前能力所不及的、看不透的东西.
5. 能力越提升,对技能的依赖越小.学会通过综合的方式去解决,而不是简单靠技能来解决,有时有些东西可能会比技能更好.

下面进入本次分享的重点,运维中的哲学问题,到底包括哪些问题?

• 敢于保证没问题是能力的体现.

就像客户经常会问,这个东西到底有没有问题,能不能100%地保证.这个其实很难保证,对运维人员来说,我想应该没有人敢这么讲.敢于承认有问题也是对自身能力的一种认可.

• 不怕有问题

不怕有问题,这是一个更高的层面.即在系统架构上,哪怕出了问题,也可以顶起来.不怕有问题是对系统架构上的自信.

• 人力终有穷尽,架构可有效补充能力不足

对于运维人员来说,最怕的是什么呢,莫过于总是想通过我的能力去确保系统不出问题.一个人再有能力,始终是有限的,而架构的保障正是弥补人力不足的一种最好手段,而且很多时候架构优化的投入成本并不大,在这种条件下,我们没有理由去放弃架构而选择人力.就算整个团队24小时轮流值班,早晚也撑不住.

• 问题又来了,能力不行,架构也设计不好

最后又绕回来了,有些东西不是绝对的,能力当然重要,架构也很重要.

在这里,我讲一个跟这有关的问题.我们可能会经常出现误操作,导致数据被删、数据丢失,这说起来不是一件很Low的事情了.像前段时间Salesforce系统丢了5小时数据,就是因为操作人员的低级失误,所以说误操作是不可避免的,我们只能尽量采取一些措施来减少发生.

对于DBA来说,最好的防御就是一方面提升自己的能力,养成良好习惯,通过工具防误操作,另一方面在一些关键操作上,实行双人审核.

对于架构师来说,设计合理的架构则是最好的防御.当数据误操作时可以快速地恢复.

什么情况下我们能做到0丢失?不同人有不同的答案.

（编辑：ASP站长网）