运维的定义（在互联网企业中运维岗位的定义）
以下内容摘自百度百科，我觉得能够代表我心中的定义（不是我没有总结概况能力:D）
运维，本质上是对网络、服务器、服务的生命周期各个阶段的运营与维护，在成本、稳定性、效率上达成一致可接受的状态。
这里很明确的指出了两个方面，运营和维护。那么在这里，我就发现了一个矛盾，我做的运维工作和它的定义的矛盾：作为网络工程师出身的我，一直将我运维工程师的岗位，理解成了维护工程师，而丢掉了运营的部分。而这丢掉的部分，也许恰恰就是我现在工作常常无法得到满意结果的原因。
就我的了解，大部分公司实际上是都对这两部分有不同的处理方式。如果重维护而不重运营（现在的我），就会大部分时间疲于奔命，只解决眼前的问题，而且往往结果还会很差；如果只重运营而不重维护，相当于只去外边开矿而不守家，经常还没有完成运营计划，现有系统已经被几个重大故障直接打垮了；还有一个情况就是两者都重视，但是将两者分开考虑，运营部门不考虑维护的情况，维护部门不清楚运营需求，最终就会两败俱伤，或者事倍功半。（运营是使用系统创造价值，维护是保障系统可用）
做为一个运维工程师，日常处理问题是必不可少的技能。往大了说，其实作为一个人，任何一个职业，都会不断处理发现问题，定位问题，解决问题。
这个小系列就让我们聊聊问题定位的方法。其实这些方法可能涉及专业知识不会太多，大部分是日常工作中思维方式的问题。但正是这些思维方式使得我们能够处理更多未知领域的更多问题，而有些思维误区则会让我们在简单的小问题上栽跟头。
信息的分类
从信息来源来说，大概可以分为
1）终端用户信息。来自于整体业务服务对象的信息，这些信息最零散，最不专业，但是他们是反应了直接影响的信息，而我们的问题解决目标也是消除这部分异常。所以这部分数据收集的最重要工作是汇聚和整理，同时也要和下层信息进行相关。
2）业务信息。来自于提供服务的业务方。他们会有服务相关的数据，能够感知很多单个用户无法感知的异常，同时又会了解业务在底层系统的运行方式，这层数据最重要的工作是将终端用户信息和底层信息做关联。
3）底层系统信息。网络工程师所在的一层，有最详细的底层数据，能够最直接反应底层设备、网络、配置的异常。但这层又是和实际用户最远的一层。
从信息采集方式来说，大概可分为
1）口述信息/体感信息。这种信息是最直观的信息，比如网页卡，网络断了这些非专业信息。或者比如：“我ping了XXX，发现丢包了，但是我没有留下操作记录”这种。这类信息因为无法证明其真实性，也无法对齐进行定量的分析，只能作为问题定位的参考。而且定位回来之后，解释这些误解也是最难的。
2）测试信息。问题出现时候，进行了相关测试的数据，并且有相应的证据。这种数据就具有一定参考性了。但是由于测试的方法，测试的时间，覆盖范围等等原因，这样的单点测试不一定能够完全帮上忙。比如我们认为物理网络已经中断，这是客户做了一个访问网页，并进行了抓包，虽然这个抓包确实能说明网络中断，但这个场景可能一个ping不通就已经证明了，再进行抓包用处也不大。
3）监控信息。这种数据可以理解为周期性进行的测试或者采集的数据，由于监控系统设计的覆盖性和全面性，它比单点测试更能说明问题。而且不同层级的监控交叉验证，也能让我们对问题有更好的定界。即使监控数据没有发现任何异常，我们也能从它的监控原理中证明XXX链路或流量没有受到影响的结论。当然，如果覆盖率太低，监控意义就和单点测试差不多了。
信息重要性优先级
按照我上边的描述，应该就能看出，我认为的重要性排序：监控信息>测试信息>体感信息。所以越高级的信息的相对准确性就越高，而当个个级别信息冲突的时候，我们更愿意相信监控信息和有证据的测试信息，然后再根据实际情况推导产生矛盾的体感信息的原因。
但是，有一点要指出，这些信息的提供方也是必须考量的一个方面，越专业的人员、系统，给出的信息肯定是更准确的。甚至，有时候老司机的直觉比其他系统更能直指问题的本质。但是我们既然要建设运维体系和系统，就是让老司机的直觉能够通过监控信息收集系统反应出来，成为组织的能力。
信息收集的难点
那么，既然我们知道了收集信息的重要性，又需要如何收集信息呢，或者说收集信息时又常遇到什么难题呢？
1）信息收集不能体系化。如果采集信息只依据每个人的经验，必然会出现漏采集，重复采集，等等各种原因。所以日常就应该形成按照问题种类，通过信息重要程度的排序，制定采集体系SOP，以便达到信息采集时谁上都一样，最好能够自动化。
2）信息采集不能自动化。不能自动化采集的最大影响除了上边的容易出错外，还有一点就是效率问题，有时问题定位要求比较高，但手动登录4~5个系统自然效率低下，不能快速获得。于是如果可以，还是需要制定自动采集的方法，甚至可以做定期信息采集，定位问题时直接使用，不用再次采集。
3）跨层，跨系统信息不能互通。不同系统、不同层级的信息能够表征的事实不同，它们有的有关系，有的没有关系，但其实这些信息都是可以互相佐证和互补的。如果这些信息能够在收集的时候进行各种关联，什么样的问题就采集多个系统，关联分析，将大大的提高效率。
4）信息覆盖面不全。覆盖率是大规模维护的痛，因为各种原因会存在信息无法采集和覆盖的情况。严重时候会导致出现严重故障。而如何提高覆盖率，或者如何在成本有限的情况下尽可能覆盖重点业务的数据监控，是各种运维系统需要持续改进的点。
结语
最后，问题定位和解决是运维日常工作重要的组成部分。而运维体系和系统就是为了能够更快速高效的解决运维问题和工作而设计的。所以我现在提到的任何一个部分，都是从人工到自动的一个过程，希望能够给运维同学提个醒，让我们尽早摆脱半夜被Call起来搞问题的生活。
系统的意义
首先，前期建设和引入系统必然会引入系统消耗，只有当收益大于消耗，引入系统才是必要的。简单来说，只有几个人的部门就没必要搞了。但是，引入系统也有一定滞后性，当部门流程足够复杂，人员已经深陷其中时再考虑引入又有点晚了。
为什么我们需要使用系统来管理这些事件？
1、将组织的流程固化，规范化。用于多部门合作和责任划分（甩锅）
2、让需要跟踪的事件状态透明化。利于事件整合和高效率跟踪（催）
3、将流程、事件格式化、数据化，便于数据沉淀分析和改进
系统的意义----以事件产生为例
事件管理系统是以事件产生为开始的，而如果需要根据上述提到原则来设计系统，这个开始就会承担最多的工作。但如果只是将发生的问题记录下来，将不会为系统带来任何益处，你就会得到一大堆各种描述不一样的问题现象事件和再发生一个问题后的一脸懵逼。
按照之前我的习惯，做事情一定是为了目的服务的，那一个事件系统的目的是什么呢？让任何事件不影响服务，或者将服务的影响性降到最低（这是整个系统的目的，后续也会重复提到）。而为了达到这个目的，在事件产生的时候，我们能做什么呢？这时第一时间进入我脑子的故事就是华佗的故事（原谅我的写作水平还停在中考水平（参加完高考退化了））。事件系统的第一目的就是让发生过的问题不再发生，在人还没病发的时候就把病治了。
所以，事件发生的第一时间就要记录：这个问题是否已经发生过，为什么会再次发生，哪个环节没有闭环（这个闭环动作会在系统的最后时刻）？
第二，既然事件已经发生，为了降低事件的影响性，可以考虑评估事件的接入方式，发现的越早，恢复的越快，设备监控>网络探测>定期巡检>业务方报障。后续进行改进时可将监控系统无法发现的问题进行沉淀，提早发现。
第三，事件输入的格式化。只有格式化的数据能够进行搜索，分类，分析。那么，系统为了服务这个要求，在事件输入的时候，几个主要的例如问题的现象分类，特殊关键字等数据就要格式化，尽量避免自然文字数据的输入。
以上就是结合系统的意义，使用事件接入阶段的例子，简单说了下系统的主要功能和设计建议。还有一个关键点，即系统的评价。任何一个系统阶段，都应该设计对应的评价标准和数据埋点，便于后期对工作的评估及改进（但改进要服务于终极目标，不能为了改进而改进）。例如：重复问题的发生率，影响业务问题的恢复率，恢复时长等。
这两天又忙的不行。主要是在整理之前出现的问题和残留的风险。因为问题多了，自然有的就会跟踪丢了，然后同样的问题又影响了业务。。。反复摔在一个坑里边是最气的。但是挖坟寻找问题的历史更痛苦。不知道一个问题的前因后果和处理办法，比不知道这个问题还痛苦。。所以继续挖坟中。后续有机会也可以写一些关于问题跟踪的系统。
今天想说的是前两天又遇到的一个业务丢包的问题。所有监控看着都是正常，但是业务告诉我们它不定期丢包，并且从他们的监控上看，确实偶尔抖动。但是，丢包完全随机，没有任何规律。
问题还得定位，怎么办呢。我们还有探测。为了能尽量模拟业务，又能覆盖所有链路，一般就是广泛的部署探测机，对所有服务器进行多端口，遍历式的探测，以便能覆盖所有设备的转发路径，包括它的芯片和接口，当他们出现问题的时候就能感知，但是这又取决于设备的转发行为。
所以基本上，我们有对设备的探测，对服务器的探测，南北向探测，东西向探测，覆盖协议的探测等等。。反正最终，在无数噪音之中，找到了一条探测流量出现了问题，根据这个探测的属性，排查到了故障设备。
因为时间精力问题，没法说的太细，只能在这唠叨两句，后续有机会再写监控系统的最后一环，主动探测。
简单回顾了一下之前的文章，发现我好像已经从网络工程师变成了自动化运维工程师了XD，那么到底我的网络技术在现在的工作里边有哪些应用呢？
运维人员的地位需要提高
监控系统再完善，也需要人来管理、维护。所以我的观点是：运维回归日常。现在基本上一直在强调系统化、自动化，一定程度上忽略了运维人员的重要性。同时，由于日常工作不容易量化，不容易有亮点，就会导致运维人员无法得到相应的报酬。于是，运维人员自己想着“升级”，哪天不做这苦逼的工作。但是，一个熟练的运维人员的工作往往是不可替代的，我们应该从上至下提升日常运维的地位，让大家能够静下心来，提升运维技能，构建最稳定的金字塔底部。
监控系统中的日常工作
我接下来会通过之前梳理的系统，简单描述一下系统中需要日常维护的工作和需要的技能。以下提到的都是网络工程师所需要的技能，系统开发的部分没有包括。
设备适配
各种通道在不同设备上实现不同，每个监控点在每个设备上都有自己的实现。这里需要的日常工作就是在新增监控节点或设备类型时定义新的适配方法。
这里需要的技能是，了解各个监控技术在设备上的实现、配置，尽量熟悉各个厂商的文档结构，注意我这里提到的是文档结构，而不是文档内容，因为没人能记住所有文档细节，只要知道如何去查就行了。（比如各个厂商的support网站在哪，他们的文档存在什么目录啥的）
通道监控，维护，修复
各个通道到设备都有可能出现问题，导致监控失效，所以需要日常维护。
这里需要的技能就是了解各个监控技术的原理，需要基本网络排障能力。比如SSH登录失败，基本套路（排名不分先后）就是网络通畅--->账户密码正确--->设备配置正确--->AAA认证正常--->设备没有bug。其中可能涉及服务器抓包等基本技能。
事件管理平台的定义
针对设备上报事件进行增、删、改查。同时优化事件处理方法。因为面对每天成堆的告警，没有人能全处理完，同时还得担心是不是有告警没有上报上来
这里需要对基本网络设备故障的有深入了解，什么样的故障需要怎样修复，什么样的现象需要定义成故障，需要怎样的阈值，都需要对自己的网络深入了解。
监控事件的处理
你需要有人盯着所有的监控，这种人需要对所有事件了如指掌，同时有标准的处理动作，能将事件根据优先级分配给不同人处理。因为现阶段自动分发的功能只能一定程度上完成这一工作，所以还是需要人。这个人还需要嗅觉及其敏锐，可以从一些蛛丝马迹中发现问题，提前发现故障。其次，你还需要一个团队处理所有监控异常，他们包括定位网络问题、变更优化和现场实施等，同时还要对问题有完整的跟踪闭环。这就引出之后我们会讲的问题跟踪系统。
这里需要的就是对网络架构，日常状态很熟悉的人，也是最考经验的地方，因为不需要经验的部分一般机器都帮你搞定了。对了，可能还需要擅长昼夜作战的人。。。因为有的运维需要24小时值班哦。
探测的设计
按照结论里边说的，探测是一种不信任设备或者说不依赖设备而产生，所以它也是一个和网络设备最不相关的系统。但是这里说的是和网络设备最不相关，可不是说的网络协议。就像做黑盒测试一样，可以基于网络功能直接进行测试，而如果所有设备都遵守协议、工作正常的话，当然我们的探测也不会出现任何问题了。
但是探测本身的设计目标就是要测试网络问题，那么，这就引入了探测的两种方向，一个是模拟业务的测试，另一个就是提高覆盖的测试。
模拟业务的测试
或者直接可以说是业务发起的测试。因为现在的数据中心的分布式设计，所有的业务模块基本都要考虑节点的存活情况。那么不可避免的，它们就要进行不停的探测。否则真到业务层面大面积timeout了才disable节点，那对业务的影响就有点大了。而这种探测的设计就要注意要和业务完全贴近了。只用单纯的ping测试或者是TCP echo探测就想证明网络设备没有问题，那你就太天真了。因为你可能真的没有见过报文超过1514才会丢弃的；或者几万个端口号都正常，就一个端口号不通的；还有TCP syn 报文没有问题，就后续特殊的标志报文丢弃的情况。所以只要你的探测和你业务有一点不同，就有可能无法探测出问题。
测试的覆盖率
现在一台盒式设备也有几十个端口，好多块芯片，而框式设备更不用说了，你要说想用一台设备几条流量的探测覆盖所有的部分是在是天方夜谈。而随着设备功能的丰富，各种报文处理的方式也变得复杂很多，绝对不是一种流量可以覆盖的了的。于是，我们就需要通过不同位置的探测源和不同种类的探测就流量，结合设备的基本覆盖分担算法、网络拓扑模型产生流量，以达到覆盖所有设备所有场景为目标。
所以大家即使在故障恢复之后反复定位，为的就是确认“为什么这个问题我们的探测没有发现？”
探测的可用性
而即使有了好的设计，探测的实现仍然十分麻烦，因为任何涉及设备的问题就不能单纯的认为是网络问题，而是一个工程问题。而工程问题我们就需要考虑到误差和成本。因为网络中随时可能产生丢包，而这些丢包也有可能是正常的，或者说不影响业务。而在这些异常的环境中，怎么能发现真正的问题呢？这个问题一直都不是不好解决的。也许后续机器学习可以解决它。因为也许我们可以建立日常的数据模型，而出现偏移的时候就是有问题的时候。比如日常每天要丢100个包，突然有一天不丢包了，那么也是可能有问题的。
而说到成本问题时候，我们就对应了探测的频度和密度。没有人能无限制的部署探测机，也不能无限制的探测设备和服务器，所以如何在成本和效果之间的平衡也是需要好好计算的。
最后的，就是可用性，因为探测本身和设备是解耦的，这就导致了我们不仅要能探测出问题，还需要能将探测固定化，因为只有故障的持续存在，我们才能一步步找到真正的故障点。另外，如果某个业务出现了故障，如果我们的探测平台能够根据线索，针对业务模型进行模拟和范围覆盖，那么就有可能在不影响业务的情况下，进行问题定位，这也是我们日常使用中常常需要的。最后，就是探测的结果展示，如果探测结果能够直接告诉我们故障设备点，就可以进行真正的自动探测隔离。于是大家想到了很多探测可视化技术，通过将探测报文进行特殊打标处理，在模拟真正业务的同时，又会携带特殊信息，当报文丢弃或者延迟异常增大的时候，就能自动显示出情况，最后当多条探测流或多个故障现象结合时，就能基本确认故障点。
设备基本信息
可包括设备的管理IP，设备名，型号，SN，物理位置等基本信息。而根据设计，可以加入设备一些维护信息、设备角色等等用于区分。其中，还有一些信息，可以从设备上获取，例如设备的版本、补丁等等。
这部分信息是所有自动化的基础，因为基本所以系统都需要知道设备基本信息才能选择对应的接口。同时，在进行设备现场操作时，物理位置信息也是必要的。
如果更详细一些，也可以记录设备上线时间或变更时间等等。
设备拓扑信息
设备之间的互联关系，链路组信息等。虽然IDC内部可以使用一些协议如LLDP或OSPF等自动计算拓扑，但是涉及互联网或接入层面的链路时，还是需要手动记录信息，用于问题分析，路径获取等等。
IP地址库
所有设备地址都需要分配，当网络规模大了，只要一不小心就会出现因为地址冲突或混乱导致的问题。这个库基本用于出现问题时进行IP的查询。
配置信息
一般来讲，我们需要标准的设备配置模板，这里需要针对不同作用的设备统一配置。其中，最好能做好设备类型的适配和配置模块的抽象。这样就能方便进行配置版本的演化和设备类型的扩充。同时也可对于新上线设备进行配置方面的校验，保证配置没有错误。
结语
以上提到的就是我能想到的一些必要的基础信息类型，可能还会有更多。看似简单，但是基础信息的维护、订正、更新却是一项必不可少的工作，它在很大程度上需要工作人员的专业性和工作流程化保证，是自动化平台基础中的基础。