（点击底部“阅读原文”获取白鳝演讲完整PPT）
大家好，今天想跟大家谈谈关于DBA怎么去考虑哲学化的问题。前段时间和朋友聚在一起时也说到，十多年前的很多DBA现在都不再干这行了，很多后面都变成哲学家了。为什么这么说呢？因为很多DBA后面都转去做架构师了。
其实在十几年前，曾有人用这样一句话来形容DBA：“你们DBA做优化就是盲人摸象”，当时我觉得这句话很不舒服，因为作为一个DBA来说，我认为这个职位在系统优化中间的价值是很大的。但随着这些年我更多地接触到一些架构的问题，慢慢从架构方面去考虑问题时，我发现，盲人摸象这种说法确实不为过。怀着这样一些想法，今天跟大家分享《运维中的哲学问题》。
不想做哲学家的DBA不是好架构师
首先，我想说的是——不想做哲学家的DBA不是好架构师！这也相当于前面我所提到的，为什么做DBA做到最后会变成哲学家呢？
就拿考虑系统的问题来说，可能刚刚入行的人，他会就着某一个东西去考虑，比如说，DBA的话可以就着数据库去着手。但随着我们的接触面越来越广，处理的问题越来越复杂时，我们就可能慢慢会从系统本身去考虑，这种情况下，有时候我们认为很多理所当然、正确的东西进入哲学范围后会发现它不对，或者不一定对，甚至是完全错误的。
包括像我，大概在十年前写的《Oracle RAC日记》这本书，前段时间我又重新把这本书翻了一下，发现里面很多的案例和关联都是错的，甚至有些案例当时的处理模式、方法是不对的。但真的不对吗？其实不一定。因为在当时它确实解决了问题，而且很多解决方法现在大家也在学。但是呢，如果转而从架构的角度去考虑，有可能当时我们的处理模式不是最好的，并没有把根本的问题解决掉。就像我们得了感冒，医生给你挂一针水，马上好了，但是如果说这个人总是感冒，总是隔三差五地去挂水，这肯定不好，必须要找到感冒的根源：是体质的问题还是其他什么问题，偏寒还是偏热，要用中医的疗法。
以前我们在内部也经常开玩笑，说当某个人考虑问题已经考虑得比较玄了，那他就已步入哲学家的行列了。如果你现在也开始学会辩证地看待问题，那么恭喜你，你已提升了一个档次，并成功晋级了。由此看来，不管作为DBA也好，还是运维人员也好，我们做系统运维，运维能力的提升都是分阶段的。
运维提升的阶段
我初步地把它总结为四个阶段。
第一个阶段为精益化，即我们把一件事情做到更好，这也是一个专业化的问题，争取在这个领域把事情做到最牛逼。
但是，光有精益化是不够的，还需要把它标准化。比如说，以前我们给用户做巡检（这是DBA接的最多的活），不同的人去做巡检，效果是不一样的，因为不一样水平的人，能够发现的问题不尽相同。后来我也一直在考虑，硬件、小机、存储这些环节的巡检都已经标准化了， 甚至可以用软件来实现。但是数据库的巡检能不能标准化呢？
2012年，我接到过这样一个项目，要给27个省（超过150套系统）做巡检，可想而知，我不可能一个人把27个省跑一遍，所以需要往27个省派出很多队伍去做。但是，这种情况下我要怎么保证27个省里大家做出来的巡检报告的水平都差不多呢？
后来经过半年的努力，我们把数据库巡检标准化这个难题给解决掉了。现在我们的公司，不管哪个员工到现场，拿着这份标准化的流程和分析方法下去，做出来的巡检报告质量都能保证水平基本一致。
从这件事情我们可以窥见到标准化的重要性。
一旦能够标准化了，下一步我们就可以考虑自动化了。现在，我们很多企业都在谈做运维自动化，但如果你企业运维的各种工具、知识体系都不标准化，你怎么做自动化？这种情况下做出来的自动化也是虚的。在这个过程中，企业采集了大量指标，做了大量的监控告警，但每天几百上千个告警跳出来，根本解决不完。这种不是在做自动化，而是给我们的运维人员添乱、添堵。所以说，我们想做自动化之前，一定要考虑运维标准化，当我们能把运维的一系列工作包括采集、分析、监控、操作等全部标准化，自动化的问题也会迎刃而解。
自动化完了下一步还需要做可视化，为什么呢？这是做完自动化以后必须做的一个环节，它既可以把采集到的大量数据通过用一种可视化的方式表现出来，也可以很好地把一些指标向运维人员展示，可以一定程度解放运维人员，降低运维的成本。但是在做可视化的过程中，我们不能再走以前的老路。
以前我们用到的运维自动化工具，都是一些商业软件，并且这些商业软件通常是基于网管式的去做，这些网管软件面面俱到，什么都能干，能够采集大量的信息，但是它不够专业。我举个例子，比如说现在我对一个系统，这个系统里面有12个网络设备，20来个服务器，不同的人看这些东西，他的关注点是不一样的，但是专业的网管软件只能采集一套数据。因此这里面就涉及到在引入可视化的时候，不单单要把数据展示出来，还要做到场景化的运维。对于哪怕同一个拓扑图，网管人员、安全人员和业务人员会根据自身关注的指标体系，看到不一样的东西，即不同的人关注不同的场景。
最后，当我们把前面所有步骤都完成了，后续就可以做智能化了，也就是引入大数据分析。通过大数据分析，我们能够发现以前很多关注不到的问题，一些以前我们知识能力达不到的分析层面。就像前段时间的阿尔法狗，有很多我们不知道的定式它也能走，阿尔法狗的出现可能会对未来下围棋的定式产生很大的影响。同时，自动化的分析对我们的IT经验、运维经验来说也是很好的补充。
系统运维工作的要点
那么，作为运维来说，运维里面的重点是什么？其实很朴素，我把它总结了几点：
以服务目录为工作核心
什么叫服务目录？很多企业可能连服务目录都不存在，一个IT部门要干什么活，是围绕着服务目录去展开的。哪些最重要，哪些不重要。如果你说任何业务我认为都是最重要的，这确实，但不现实。
以服务级别协议为服务依据
区别好哪个系统是四个九，哪个系统是五个九。一定要跟业务签订服务级别协议。
以保障业务为工作目标
不能为了运维而去运维，甚至通过运维去催发出一些新的事，这是不可取的。
以标准化工艺为指导
标准化工艺是相当重要的。以前我们也经常会碰到，同样一套系统，有多个服务器，里面配置的参数都不一样，这些都是不规范的做法。
以运行基线为判断依据
随着运维的规模越来越大，场景越来越复杂，我们一定要用一些自动化工具作为辅助手段，光靠人力是愈来愈难满足企业的需求。另外，在进行分析的时候，系统到底健不健康、存不存在问题，要以运行基线作为依据。
以事件跟踪为工作方法
当出现问题时，通过疑点跟踪，发现有价值的问题。
以闭环管理为考核策略
任何一个疑点，都必须闭环，这也可以作为管理的一个目标。
不同阶段的运维人员
不同阶段的运维人员，分析方法、思路是不一样的。
首先，刚入行的，往往会根据现象去分析问题，可是如果碰到一些“超自然”现象就束手无策了。其实不存在诡异的“超自然”现象，任何现象都是有根源的，只是能力认知范围上的不足。
随着能力的提升，我们可以通过抓到系统运营的一些指标、基线去分析问题。但是，光是有指标和基线也仍然不够，假设我们判断一个系统是不是已经达到它的负载极限，是需要根据系统容量来判断的，比如说这个存储能提供多大的IOPS，超过多少额度颜色会上升，运维人对于这些容量指标体系必须有所了解。
另外，如果再往架构师方向发展，就会从整体角度来思考，辩证地看待问题。达到这一地步的话，我们可戏称这人“成精”啦，因为他已经超脱了普通的一种运维范畴。
如何辩证地看待问题
举几个比较典型的点：
没有绝对的对错。以前DBA圈特别在意对和错的问题，这是不对的，有些网站上就常常有人为了某个处理方法天天打架。但是随着个人能力的提升，对错这个观念可能就越来越淡。
过犹不及。我们总是希望把事情做到最好，讲究“工匠精神”，但实际来说，有时候过了还不如不过。
与过犹不及类似的，最佳方案也许是最坏的。在前些年阿里的Oracle数据库架构中就有个远程维度的问题，当时圈里也做了很多的探讨。就说这个维度会对我的运维带来多大的负担，有没有必要。前段时间我刚好碰到这样一个用户，他也想用这个方案来实现他的性能高可用，但他的使用方法是存在问题的，因为他没有掌握阿里当时使用这个时的精神，简单地去操作这个方案，结果数据库打不开。
眼见不一定为实。即可能有更深层的东西，以前我们碰到的称之为“灵异的问题”，也是因为这里面有你目前能力所不及的、看不透的东西。
能力越提升，对技能的依赖越小。学会通过综合的方式去解决，而不是简单靠技能来解决，有时有些东西可能会比技能更好。
运维中的哲学问题
下面进入本次分享的重点，运维中的哲学问题，到底包括哪些问题？
敢于保证没问题是能力的体现。
就像客户经常会问，这个东西到底有没有问题，能不能100%地保证。这个其实很难保证，对运维人员来说，我想应该没有人敢这么讲。敢于承认有问题也是对自身能力的一种认可。
不怕有问题
不怕有问题，这是一个更高的层面。即在系统架构上，哪怕出了问题，也可以顶起来。不怕有问题是对系统架构上的自信。
人力终有穷尽，架构可有效补充能力不足
对于运维人员来说，最怕的是什么呢，莫过于总是想通过我的能力去确保系统不出问题。一个人再有能力，始终是有限的，而架构的保障正是弥补人力不足的一种最好手段，而且很多时候架构优化的投入成本并不大，在这种条件下，我们没有理由去放弃架构而选择人力。就算整个团队24小时轮流值班，早晚也撑不住。
问题又来了，能力不行，架构也设计不好
最后又绕回来了，有些东西不是绝对的，能力当然重要，架构也很重要。
在这里，我讲一个跟这有关的问题。我们可能会经常出现误操作，导致数据被删、数据丢失，这说起来不是一件很Low的事情了。像前段时间Salesforce系统丢了5小时数据，就是因为操作人员的低级失误，所以说误操作是不可避免的，我们只能尽量采取一些措施来减少发生。
对于DBA来说，最好的防御就是一方面提升自己的能力，养成良好习惯，通过工具防误操作，另一方面在一些关键操作上，实行双人审核。
对于架构师来说，设计合理的架构则是最好的防御。当数据误操作时可以快速地恢复。
什么情况下我们能做到0丢失？不同人有不同的答案。
领导可能会说，最好能做到不丢失数据。一些解决方案厂家，他们可能会说：用了我的系统、我的产品就能做到数据不丢失。那么作为DBA，我们可能希望通过自己的技能或方案来做到0丢失，但是架构师考虑的角度就不一样了，他首先考虑到我要做到数据0丢失，成本是什么？我的系统需不需要做到0丢失？大家可能认为，对银行来说很需要数据研究师，但我和很多商业银行的IT主管交流时，他们认为丢一点数据没关系，只要不错就行了。
首先，我们必须明确运维自动化的目的是把运维人员从繁琐的运维监控工作中解放出来，但实际上“运维自动化程度越高运维人员越忙”却是现在的普遍认知。正如前面所说，自动化运维平台能够发现更多的事件，呈现更多的数据给运维人员，可这些问题是不是值得我们马上去处理，这需要一些分析和筛选。
另外，我们在做基线分析的时候，如果定了一些不合理的基线指标，就会导致告警数据越来越多，上述状况都会导致我们的运维人员越来越疲于奔命。比方说，我们定义CPU超过90%就会报警，但其实超过90%是不是就是一个必须解决的问题呢？不一定，需要根据各自的实际应用场景去分析。
所以在这一块，我们的运维自动化平台不只是简单监控就行了，还需要大量运维经验的人才。没有运维经验的自动化平台就是个虚的东西，没有任何价值。
创造力是企业竞争力提升的源泉，但是反过来，标准化是企业长期生存的依靠。光有创造力、天天有新点子，却不能沉淀到企业里面来，无法成为企业的血液，这个企业也没办法把自己的创造力转化为生命力。
对于运维而言，创新和标准化是螺旋上升的关系，既要有创造力，又要标准化，这两个相辅相成，不能脱节。
再者，我们在企业里是一个团队，创造力再强的人也必须遵循标准化的管理要求，反过来标准化不能束缚死了，阻碍运维创新。因此，从企业选择运维人员的角度看，稳健型IT更需要标准化，创新型IT更需要创造力。
对DBA来说，一般发现问题可能会惯性地去找一些SQL的问题，通过SQL优化可以很快把难题解决掉。SQL优化的作用很明显，但是反过来，我们也常常发现SQL优化会引起更深入的问题。
从运维的角度，我们再看回前面“DBA做优化是盲人摸象”这句话，会觉得不无道理。因此，我们在做优化的时候必须通盘考虑整个基础架构，而不仅仅是一个面。
那么，一个优化项目必须具备哪些成功要素？
在我看来，必须囊括扎实的客户调研、深入全面的分析和对IT基础架构的充分了解这三个要素。尤其是对整个架构的把握，如果你不了IT系统架构，你就只能从SQL层面去优化，永远是治标不治本。
最后，我们总结一下本次分享：对运维来说，没有绝对的最好，但不妨碍你去追求最好；没有绝对的正确，但不妨碍你探索正确的道路。人才是智慧的源泉，再强的自动化运维平台都需要高智商的运维人员。
讲师介绍 白鳝
徐戟，网名白鳝，DBAplus社群联合发起人。20多年应用开发、运维管理、系统优化、IT队伍管理工作经验。著有《Oracle RAC日记》、《Oracle DBA优化日记》等技术专著。
曾主持开发了国内首套电信级联机实时计费系统、国内第一套三检合一的检验检疫综合管理系统、国内第一套公路口岸快速通关系统以及银行大前置平台（IPP）。信息无障碍研究会专职顾问，Oracle ACE。