业务总结

运维工作的特点以及难点：

系统运维工作是计算机工作的一类。与软件开发所不同的是，系统运维更侧重软件在真实运行时候的性能以及稳定性表现。更注重软件运行的连续性以及软件和硬件之间的关系。     Pascal之父--Nicklaus Wirth有一句名言:”算法+数据结构=程序”。他凭借这样一句话获得了1984年图灵奖。但是一个好的软件并不等于程序。因为除了程序本身的功能以外，大规模可维护性和可扩展性却似乎成为了一个更大的困难，困扰着软件工程师不在是数学意义上的技术难题，而是复杂的工程学方法。软件工程师利用这些方法把程序巧妙的组合在一起。每个部分都有自己的用处，我们称之为架构和模式。定义又发生了变化：软件=程序+架构+模式。但是，单纯的软件还不能称之为真正的系统。要想成为系统，还要有使其变为现实的硬件资源。因此，系统=软件+资源环境。而我们运维工作，是要直接面对的是一个个正在运行的系统。这是一个非常复杂的问题，而非重启服务这么简单。我们只能根据理论从某个侧面描绘这个过程的样子，却无法直接窥探他本身。很多时候我们会陷入一种幸运而又尴尬的境地：没错，这个系统看起来正在工作，而且工作的很好。这个并不是为问题，问题是我们也许我们并不知道他为什么会工作的很好，正如我们无法预测到他什么时候会变得不好一样。


运维工作的工作目标以及工作方法：

很多时候，我们的工作目标用一句话或者是一个词总结，叫做业务连续性。好比一个永不打烊百货商店。客户希望你能够永远提供服务，不管什么时间，什么地点，多少人来，这个服务都能够得到保证。很遗憾的是，这个看似很简单的问题却非常难以达到。不完全是技术达不到，而是成本不允许。因此，我们的目标退而求其次，变成了在有限的成本下，能够最大化业务连续性。为了达到这个目标我们需要考虑到以下问题。


1系统的冗余性和单点故障

系统的冗余性设计决定了系统连续工作的能力，我们需要考虑我们的系统是否有充分的冗余，保证任和一个部件出现故障，不会影响到我的整个系统？如果有这个冗余，如果变成了单点，我们的风险有多大？如果做成冗余，他所需要的成本是多大。这个成本是否还能带来性能上的提升？冗余的方案多种多样，例如硬盘raid带给我们冗余性的同时成倍提升了机械磁盘的能力；透明多路径除了带给我们冗余性的同时还能够给我们带来一倍的带宽；虚拟化在解除软件硬件耦合性的难题外还能够整合我们多余的资源。等等问题，我们都要综合考虑。

2 系统如何进行升级

在系统搭建的时候，我们就需要考虑这些系统以后将如何升级来满足用户数量级的提高和软件的版本更新。这个系统能否平滑的横向升级，还是只能通过硬件的更新换代来进行纵向升级。平滑升级意味着软件需要非常好的设计，而纵向升级则意味着大量的硬件成本。幸运的是，我们有了虚拟化这个灵丹妙药，他可以在很多情况下帮助我们解决纵向升级的难题。我们利用这个技术，解除了系统硬件的三要素——CPU/mem/hdd的耦合性。有助于我们把复杂的模型简单化。

3 如何扩展这个系统的可管理能力

运维工作中有太多的重复性的，有规律的工作。我们一个重要的工作是把这部分工作从自身的劳动中分离出来，把他变成自动化或者半自动化的工作。我们要把轮询的检查机制更改成基于事件的消息机制。让这些工作更加及时地，安全地有效率地运行。这也有助于我们集中精力处理真正的问题。要做到这点，需要合适的工具和一定的编程技巧。软件工程有个著名的观点——不要重复发明轮子。工程师信奉拿来主义的实用性哲学。如果别人的免费的工具能够帮助我们解决问题，那么我们就要使用别人的工具。如果别人的收费的工具的费用成本比自己开发这个工具的成本低，我们就使用别人的。而现实上，这个世界上存在着众多强大的自由软件，能够帮助我们解决相当多的问题，降低IT运营的成本。

4. 如何科学的衡量一个系统的真实性能

指标或者基准一直是一个被忽视的最重要的要素。计算机是一个异常复杂的机器。那些cpu都在以每秒数十亿次的速度进行运算。问题的复杂程度如同湍流。除了宏观的统计方法，很难真正理解其行为。而这些数字之中就隐藏着揭示一切谜题的真相。而对于这些数字指标真正意义的正确理解，能够让我们知道系统中各项机制所处的情况。我们需要对各项指标在不同情况下的数量级大小有着直觉般的感受。有助于帮助我们在系统异常的情况下判断问题的根源，也有助于在性能无法满足要求的时候判断系统的性能的瓶颈。另外，性能问题的真正含义不在于相应速度慢，而在于真实速度比设计的正常速度慢了多少。大部分性能问题绝非在运维的过程中所产生的，而是发生在程序设计阶段。我们所能做到的，就是比较这些基准的变化。

5. 如何衡量一个系统的安全性

衡量安全性的最大的难题是你只能证明一个系统是不安全的，确无法证明一个系统是安全的。这个问题就像图灵机停机一样让人困扰。我们唯一所能做的就是尽可能评估和排除掉导致不安全的因素，并如履薄冰地接受实践的检验。

6. 如何进行灾难恢复

运维工作中最重要的一项问题就是如何最快把遭到破坏的运行环境恢复到灾难发生之前。这个原理也许并不复杂，但却因为极少遇到，让这些经验变得非常宝贵。


总之，对于以上问题的不断思考，促成了我们在不增加成本的同时，让我们的服务质量的不断提高。

运维工作的技能和技巧：

毫无疑问的是，计算机运维是计算机信息技术的一种。我们需要的技能多半是和计算机相关的。我列举了一些工作中比较重要的技能和技巧，对这些知识的学习和领会能够帮助我们成为一个更出色的运维工程师。


1. 我们所需要掌握的是操作系统的特性和与之交互的方法。

无论是gui,还是cui，无论是采用第三方工具，或是用系统指令，再或利用系统api自制工具，目的都是能够让操作系统完成他能够完成的功能。这需要一定的编程技巧。但是，与软件开发不同的是，系统管理员更注重功能的实现。对于性能、可重用性、可维护性、用户界面和输入检测等要求并不高。

2. 我们需要理解计算机和操作系统以及网络的基本原理。

在计算机中，所有的概念都是经过了层层抽象的。例如文件，进程，实际上，这些东西从来不是真正存在的。我们需要一些知识，将这些概念实体化并理解。掌握这个技能有助于我们理解数据在不同的速度的设备中的流动。

因为相当多的系统并不能自动根据运行时不同的使用情况自动优化，而是采用满足大多数情况最优的通用配置。理解系统的内部机制可以帮助我们修改各项参数来适应我们当前的使用情况。

从现实角度讲，大部分程序的性能往往不取决于程序本身的算法的时间复杂度，而取决于程序对于上一层缓存的亲和性，取决于IO调用的等待模型。因此架构的调整所获得的收益很有可能是超出预想的。

3. 我们需要掌握经典的算法和数据结构知识帮助我们理解系统中某些问题的性能和特性。

依赖渐进的方法，我们可以忽略掉硬件的差异，直接思考问题在极大数量规模下的性能表现。

4. 我们需要大量经验来规避系统运行中的各种风险。

很多重要的问题在理论上是非常简单的，但是这些简单的问题却经常被忽略，造成了极大的危害。除了经验，没有别的方法。

5. 我们需要非常好的逻辑思维能力和大量经验帮助诊断和解决信息系统中出现的各类问题。

“Everything happens for a reason”。机械论者们相信这个世界只存在因果，而不存在随机。上帝也从来不掷色子。他们尝试把一切问题的本源归结为物理定律作用的结果。很遗憾的是，我们称之为科学。而且这个哲学观点而对于诊断尤其具有意义。

诊断的过程很多时候是一个不断否定命题的过程。一般逻辑是这样的：我们根据经验对症状所导致的原因进行排序。先假设这个命题是正确的，在想办法验证他是错误的。如果他是错误的，我们就进行下一次猜测，同时这个检验结果也成为了帮助我们判断的要素。可是检验通过也不能说明该命题是正确的。但是我们可以假设他是正确的，并按照这个结论来处理。如果失败，则证明这个命题是不正确的，如果成功，那么我们的理论很可能是正确的，同时我们解决了这个问题。

尽管这个逻辑很简单，但是不同问题的诊断的难易度还是有很大差别的。最简单的区别鉴别法只要通过不断更换部件就可以缩小范围。比较复杂的问题可能非常难于捕捉和复现。你可能很难观察到问题发生的过程，有些情况甚至你诊断所采用的观测方法会像海森堡测不准原理那样会不知不觉地改变问题发生的机制。解决这类问题可能有需要一定的猜测的运气或者说天分了。



ps:应付公司职称评审要求的3千字业务总结。