一、基础数据概况
CMDB中文是配置管理数据库，存储与管理企业IT架构中设备的各种配置信息，与未来的IT运维管理标准化和流程化紧密关联，并且支持流程的运转。运维管理平台创建初期或初版中的CMDB更多是偏向IT资产管理，我们在这里定义的IT资产管理，暂时抛除公司个人使用的普通PC机。
日志主要存储CMDB中涉及到服务器或是其它设备的日志信息。
DB主要是所有IT系统的数据库信息，包括运维管理系统本身的数据库。由于数据库的重要性，所以在基础数据中单独一个模块管理数据库，包括生产数据库、测试数据库、开发数据库。数据库的日志放在日志模块进行统一管理，监控和备份。
知识库主要存储日常运维管理中发生的事件、问题以及一些经典问题的解决和常用的解决方案，主要起到运维管理辅助的功能。
二、基础数据三要素
基础数据要求完整、准确、实时，这三个特性缺一不可。
1完整性
完整性，要求在数据采集整理阶段，要一一梳理，不能有遗漏。任何一个设备的疏漏都将会导致未来出现问题。例如最近的勒索病毒在防范上需要给服务器升级打补丁，这个时候就是根据服务器清单一一对照，升级。如果有遗漏落下的服务器未及时打补丁而导致病毒入侵，后果将很严重。那么，如何做到完整性呢？大致可以分为以下几步：
首先数据采集阶段多人（推荐三人以上）同时对IT资产进行采集，那么在数据采集完成后，将会有三份或以上的IT资产清单。
接下来就是相互确认阶段。相互check对比两方的清单和自己梳理的清单，找到不一样的地方，大家在一起开会进行讨论。经过这个阶段，会产生一份相对完整且三方（或以上）认可的IT资产清单。
最后就是三方（或以上）一同针对认可的IT资产清单进行最终check，确保最后的清单，是经过多方讨论确认，并最终又check过的IT资产清单。此时这份IT资产清单，相对比较完整。另外在梳理、讨论和check的过程中，针对新增、变更、删除的IT资产一定要及时更新我们的IT资产清单。
2准确性
准确性要求IT资产清单或是CMDB中存储的数据不能与实际情况有任何差异。要做到基础数据的准确性除了在数据采集阶段要下功夫外，要在运维管理的每一个阶段定期对基础数据进行审计，确保基础数据中的数据无误。一般月度一小审，半年一大审，具体情况根据企业的IT规模而定。
3实时性
基础数据的实时性可以确保数据的准确性。即基础数据的每一次变动，包括增加、删除、修改，不论大小，只要有变动（在运维流程完结阶段，执行运维 *** 作成功后，就要及时更新基础数据。忽略基础数据的实时性，必将导致准确性大打折扣，在以后的月审、年审中必将导致额外的工作量。一般在审计的过程中，当数据的错误率达到一定程度后，需要重新梳理全部数据，以确保最终的准确和完整。
CMDB
CMDB总的来说分为：产品线、资产管理、供应商管理三个部分。
总的思路是：通过产品线管理IT资产，通过IT资产信息管理硬件或服务提供者，供应商管理。
1产品线
产品线是指整个公司所有IT系统、产品按照属性进行归类划分。这有一个前提，就是梳理整个公司的IT项目和IT服务。这里项目也可以理解为每一套IT系统，例如OA、CRM、订单系统、支付系统等等。
IT服务主要是指：应用服务（Tomcat、WebLogic、数据库服务等），基础IT服务如Nginx、Varnish、Redis等。通过项目和服务两个维度来管理IT资产，尤其是虚拟机。因为一般系统和服务都是部署在虚拟机上，虚拟机的宿主机则是一台台物理主机。
产品线的划分一般除了根据业务分类划分几个大的产品线外，还需要划分一些基础产品线，如：信息安全产品线，主要管理信息安全、网络安全等系统和设备等;基础服务产品线，如Nginx反向代理大部分系统，Varnish缓存Web静态资源等。
在这里单独说一下产品线和项目包括的服务必须制定运维优先级等级。运维等级的制定不能简单定义为多少级，而应该是为每一套系统进行运维优先级打分，分值不能一样。这样保证在大面积故障的时候，可以根据优先级解决问题。
2资产管理
资产管理主要有以下几个方面。
首先是比较大的机房管理。有的企业可能会有多个机房，每个机房的基础信息，如带宽、位置、值班电话等都需要加以整理存储用来管理机房信息。机房中的机架、机柜、交换机、路由器等硬件信息，机房的空调、UPS电源、环境监测系统等都属于机房管理的范畴。
安全设备管理。安全设备管理这里主要包含防火墙、IPS、WAF、等网络设施。企业信息安全非常重要，在运维管理中也把安全作为一个单独的模块进行管理。通过购买安全硬件设备和安全服务，不断学习和研究，从而保护好企业数据信息。
服务器管理。这里假定企业实现了虚拟化，大部分系统和服务都部署在虚拟机，而虚拟机是部署在物理机上。服务器管理分物理机和虚拟机分开管理，同时又密切关联。虚拟机在哪一台或几台物理机需记录清楚。
根据产品线中定义的运维优先度等级，在资产管理中的每一个节点标注上相应的等级分值，以便出现大规模故障，有选择、有重点、有顺序地逐一解决问题。
3供应商管理
供应商管理主要是管理由第三方企业提供的IT系统或设备的服务信息。记录供应商的具体信息、值班电话、硬件备件库等信息。
以上几个模块单独管理，但是又密切相连。如产品线包含哪些项目，包含哪些服务，这些项目和服务部署在哪些虚拟机上，虚拟机又在哪一些物理机上，物理机分布在哪些机房和在机房中的具体位置，物理机在机房中的网络位置和网络架构如何，经过哪些安全设备等等。
反过来需要知道某一些机房有哪一些物理机，物理机位置，安全设备，以及安全设备与物理机的网络架构等，物理机上又有哪些虚拟机上部署了哪一些项目和服务等。系统和服务属于哪些供应商提供，供应商又提供了哪些系统、设备或服务器等。都要多维度进行管理。要求做到某一环节的故障，一查就知道所有受影响的系统和服务。CMDB中的信息相互交织，多维度查询和管理，构建出一张完整的总体架构图，通过总体架构图除了展现出各个部分的基础信息外，还描述了所有的依赖关系，做到坏一点而知全面。
日志
通过日志可以比较准确全面地知道系统或是设备的运行情况，可以返查问题产生的原因，还原问题发生的整个过程。通过日志也可以提前预测系统可能要发生的问题或是故障，如系统安全日志，如果网络攻击会在系统安全日志中有一定的体现。
1系统日志
系统日志主要指的是 *** 作系统的日志，主要在/var/log下的各种日志信息。包含系统 *** 作日志、系统安全日志、定时任务日志等。系统日志是运维管理安全模块中审计的重要依据。一般默认的 *** 作系统日志不能满足要求，需要对系统的参数进行修改，如为history命令加上时间戳、IP，并且长久保留历史等功能。并且对日志文件进行处理，不允许用户进行清空命令，只能append。
2应用日志
应用日志主要记录应用服务的健康运行情况以及业务 *** 作的具体日志两部分。应用监控运行情况反应应用服务的健康状态，如果应用占用CPU或是内存过高或是忽高忽低不定，都可以通过分析应用日志结合业务 *** 作日志得出结论。业务 *** 作日志可以为业务审计提供主要依据。有一些系统喜欢把业务 *** 作日志写到数据库中，这个也是需要注意的。不过不管在哪个地方，要求是不可缺少的，它为以后业务审计和问题返查提供依据。
3数据库日志
数据库日志主要反馈数据库的运行情况。通过监控和管理数据库的日志，及时了解数据库的运行情况，遇到问题及时解决等。可以通过数据库日志结合数据库系统自带的数据库如Oracle的系统视图v$开头，MySQL的performance_schema等。虽然数据库的一些信息不是存在日志中而是在数据库里面，但是也可以作为数据库日志的一部分进行管理和监控，已便我们及时知道数据库的监控状况，从而预防可能出现的问题。
4设备日志
设备日志一般是一个比较容易忽略的地方，但设备日志往往可以反映设备的运行情况。交换机故障，防火墙故障等设备故障都可能引起大面积的系统和服务故障。所以设备日志一定要收集，分析和监控预警。常用的设备日志有交换机日志、防火墙日志、网络安全设备日志等。
在CMDB中梳理的IT基础设施的基础上，对日志进行分类收集、管理、分析和监控，配着监控管理模块的系统，就已经可以达到多方位监控IT系统，保障IT系统的安全稳定。
DB
由于数据和数据库的重要性，在基础数据中，数据库作为单独的模块存在，根据环境划分为：生产数据库、测试数据库、开发数据库。严格区分三种环境的数据库，避免测试数据到生产环境，生产数据到测试环境等。另外数据库中数据也为业务监控提供数据依据。通过查询数据库中的数据，依据业务逻辑进行判断是否有错误或是遗漏的数据。
知识库
知识库在整个运维管理中是一个辅助功能，主要为运维提供事件管理、问题管理。很多朋友可能会疑惑为什么把事件库和问题库放在知识库这里，这些不是应该在CMDB中吗？这里稍微解释一下，其实本人也并不太清楚这种办法是否可行。在CMDB模块中更多是偏向IT资产管理，为以后的运维 *** 作提供运维范围和运维目标。而事件（主要指运维过程中遇到的所有的运维事件）和问题（需要进行变更发布才能解决的事件升级）更多是在IT资产之上，是解决IT资产的过程中遇到的事件和问题。如果把CMDB作为IT运维的基础管理对象和范围目标的话，事件和问题应该单独出来。也许在后面的运维管理中，逐渐强化CMDB的功能，会把事件库和问题库回归到CMDB模块中。
知识库中还包含经典案例库，主要是解决一些常遇故障、经典问题的解决方法的整理和归档。
解决方案库只要是一些常用的或是探索中的解决方案，例如：Nginx+Tomcat+Redis部署方案，FastDFS分布式文件服务器方案等。
文档库主要用来存储运维管理过程中执行的运维标准和规范以及运维的流程规范，常用的一些规范举例：
文档库也包括一些企业或是部门的规章制度，与供应商的合同条文等。主要是涉及到IT系统文档的一个存放和查阅的地方。
运维标准和运维流程的文档一定是必不可少的。因为运维自动化的前提就是运维的标准化和流程化。如果没有明确的标准和规范的流程，运维自动化就只能一直停留在测试环境的假想空间中。
总结
基础数据在整个运维管理中起到基础、奠基的重要作用，也是做运维管理平台的第一步和以后每一步的重要依据。一定要舍得投入时间、人力等来建立起完整、准确、实时的基础数据。打好地基，以后运维的每一步都将有条不紊地循序渐进，终将建设成属于运维的高楼大厦。
随着信息时代的持续发展，IT运维已经成为IT服务内涵中重要的组成部分。面对越来越复杂的业务，面对越来越多样化的用户需求，不断扩展的IT应用需要越来越合理的模式来保障IT服务能灵活便捷、安全稳定地持续保障，这种模式中的保障因素就是IT运维（其他因素是更加优越的IT架构等）。从初期的几台服务器发展到庞大的数据中心，单靠人工已经无法满足在技术、业务、管理等方面的要求，那么标准化、自动化、架构优化、过程优化等降低IT服务成本的因素越来越被人们所重视。其中，自动化最开始作为代替人工 *** 作为出发点的诉求被广泛研究和应用。
IT运维从诞生发展至今，自动化作为其重要属性之一已经不仅仅只是代替人工 *** 作，更重要的是深层探知和全局分析，关注的是在当前条件下如何实现性能与服务最优化，同时保障投资收益最大化。自动化对IT运维的影响，已经不仅仅是人与设备之间的关系，已经发展到了面向客户服务驱动IT运维决策的层面，IT运维团队的构成，也从各级技术人员占大多数发展到业务人员甚至用户占大多数的局面。
因此，IT运维自动化是一组将静态的设备结构转化为根据IT服务需求动态d性响应的策略，目的就是实现IT运维的质量，降低成本。可以说自动化一定是IT运维最高层面的重要属性之一，但不是全部。
1 IT运维
IT运维是IT管理的核心和重点部分，也是内容最多、最繁杂的部分，该过程主要用于IT部门内部日常运营管理，其涉及的对象分成两大部分，即IT业务系统和运维人员；业务运维是业务需求和用户体验的核心和重点部分，更是需要对内容繁杂、持续变化、支持不同的业务需求，加以描述、加载和维护的过程，其涉及的对象包括2类人员，一类是提供业务支持的技术人员，另一类是整个组织的管理层和业务骨干，随着业务运维环境和工具的能力提升，功能完善、体验优化，技术人员将逐步退出这个领域；日常管理运维则是对IT运维和业务运维需求、过程、结果的管控，以及对整个管理信息系统运行状态的管控，从而实现针对应用变化的记录和跟踪、针对地域不同的变更和跟踪、预测环境和应用的风险和防范管理等等，其涉及的对象主要是运维管理部门的管理人员和参与人员。
2 业务运维
包含对企业自身核心业务系统运行情况的监控与管理，对于业务的管理，主要关注该业务系统的CSF（关键成功因素Critical Success Factors）和KPI（关键绩效指标Key Performance Indicators）。
3 日常管理运维
该部分主要用于规范和明确运维人员的岗位职责和工作安排、提供绩效考核量化依据、提供解决经验与知识的积累与共享手段IT运行维护管理的每一个子系统中都包含着十分丰富的内容，实现完善的IT运维管理是企业提高经营水平和服务水平的关键。运行/维护阶段与服务/支持阶段的分界线为前者是面向 IT部门内部的管理，而后者是面向业务部门、企业中的其它人员或直接面向客户。
参考资料：
要点一：架构独立
任何架构的产生都是为了满足特定的业务诉求，如果我们在满足业务要求的同时，能够兼顾运维对架构管理的非功能性要求。那么我们有理由认为这样的架构是对运维友好的。
站在运维的角度，所诉求的架构独立包含四个方面：独立部署，独立测试，组件化和技术解耦。
独立部署
指的是一份源代码，可以按照便于运维的管理要求去部署、升级、伸缩等，可通过配置来区分地域分布。服务间相互调用通过接口请求实现，部署独立性也是运维独立性的前提。
独立测试
运维能够通过一些便捷的测试用例或者工具，验证该业务架构或服务的可用性。具备该能力的业务架构或服务让运维具备了独立上线的能力，而不需要每次发布或变更都需要开发或测试人员的参与。
组件规范
指的是在同一个公司内对相关的技术能有很好的框架支持，从而避免不同的开发团队使用不同的技术栈或者组件，造成公司内部的技术架构失控。
这种做法能够限制运维对象的无序增加，让运维对生产环境始终保持着掌控。同时也能够让运维保持更多的精力投入，来围绕着标准组件做更多的效率与质量的建设工作。
技术解耦
指的是降低服务和服务之间相互依赖的关系，也包含了降低代码对配置文件的依赖。这也是实现微服务的基础，实现独立部署、独立测试、组件化的基础。
要点二：部署友好
DevOps 中有大量的篇幅讲述持续交付的技术实践，希望从端到端打通开发、测试、运维的所有技术环节，以实现快速部署和交付价值的目标。可见，部署是运维日常工作很重要的组成部分，是属于计划内的工作，重复度高，必须提升效率。
实现高效可靠的部署能力，要做好全局规划，以保证部署以及运营阶段的全方位运维掌控。有五个纬度的内容是与部署友好相关的：
CMDB配置
在每次部署 *** 作前，运维需要清晰的掌握该应用与架构、与业务的关系，为了更好的全局理解和评估工作量和潜在风险。
在织云自动化运维平台中，我们习惯于将业务关系、集群管理、运营状态、重要级别、架构层等配置信息作为运维的管理对象纳管于CMDB配置管理数据库中。这种管理办法的好处很明显，集中存储运维对象的配置信息，对日后涉及的运维 *** 作、监控和告警等自动化能力建设，将提供大量的配置数据支撑和决策辅助的功效。
环境配置
在运维标准化程度不高的企业中，阻碍部署交付效率的原罪之一便是环境配置，这也是容器化技术主要希望解决的运维痛点之一。
腾讯的运维实践中，对开发、测试、生产三大主要环境的标准化管理，通过枚举纳管与环境相关的资源集合与运维 *** 作，结合自动初始化工具以实现标准环境管理的落地。
依赖管理
解决应用软件对库、运营环境等依赖关系的管理。在织云实践经验中，我们利用包管理，将依赖的库文件或环境的配置，通过整体打包和前后置执行脚本的方案，解决应用软件在不同环境部署的难题。业界还有更轻量的容器化交付方法，也是不错的选择。
部署方式
持续交付原则提到要打造可靠可重复的交付流水线，对应用软件的部署 *** 作，我们也强烈按此目标来规划。业界有很多案例可以参考，如Docker的Build、Ship、Run，如织云的通过配置描述、标准化流程的一键部署等等。
发布自测
发布自测包含两部分：
应用的轻量级测试；
发布/变更内容的校对。
建设这两种能力以应对不同的运维场景需求，如在增量发布时，使用发布内容的校对能力，运维人员可快速的获取变更文件md5，或对相关的进程和端口的配置信息进行检查比对，确保每次发布变更的可靠。
同理，轻量级测试则是满足发布时对服务可用性检测的需求，此步骤可以检测服务的连通性，也可以跑些主干的测试用例。
灰度上线
在《日常运维三十六计》中有这么一句话：对不可逆的删除或修改 *** 作，尽量延迟或慢速执行。这便是灰度的思想，无论是从用户、时间、服务器等纬度的灰度上线，都是希望尽量降低上线 *** 作的风险，业务架构支持灰度发布的能力，让应用部署过程的风险降低，对运维更友好。
要点三：可运维性
运维脑海中最理想的微服务架构，首当其冲的肯定是可运维性强的那类。不具可运维性的应用或架构，对运维团队带来的不仅仅是黑锅，还有对他们职业发展的深深的伤害，因为维护一个没有可运维性的架构，简直就是在浪费运维人员的生命。
可运维性按 *** 作规范和管理规范可以被归纳为以下七点：
配置管理
在微服务架构管理中，我们提议将应用的二进制文件与配置分离管理，以便于实现独立部署的目的。
被分离出来的应用配置，有三种管理办法：
文件模式；
配置项模式；
分布式配置中心模式。
限于篇幅不就以上三种方式的优劣展开讨论。不同的企业可选用最适用的配置管理办法，关键是要求各业务使用一致的方案，运维便可以有针对性的建设工具和系统来做好配置管理。
版本管理
DevOps持续交付八大原则之一“把所有的东西都纳入版本控制”。就运维对象而言，想要管理好它，就必须能够清晰的描述它。
和源代码管理的要求类似，运维也需要对日常 *** 作的对象，如包、配置、脚本等都进行脚本化管理，以备在运维系统在完成自动化 *** 作时，能够准确无误的选定被 *** 作的对象和版本。
标准 *** 作
运维日常有大量重复度高的工作需要被执行，从精益思想的视角看，这里存在极大的浪费：学习成本、无价值 *** 作、重复建设的脚本/工具、人肉执行的风险等等。
倘若能在企业内形成统一的运维 *** 作规范，如文件传输、远程执行、应用启动停止等等 *** 作都被规范化、集中化、一键化的 *** 作，运维的效率和质量将得以极大的提升。
进程管理
包括应用安装路径、目录结构、规范进程名、规范端口号、启停方式、监控方案等等，被收纳在进程管理的范畴。做好进程管理的全局规划，能够极大的提升自动化运维程度，减少计划外任务的发生。
空间管理
做好磁盘空间使用的管理，是为了保证业务数据的有序存放，也是降低计划外任务发生的有效手段。
要求提前做好的规划：备份策略、存储方案、容量预警、清理策略等，辅以行之有效的工具，让这些任务不再困扰运维。
日志管理
日志规范的推行和贯彻需要研发密切配合，在实践中得出的经验，运维理想中的日志规范要包含这些要求：
业务数据与日志分离
日志与业务逻辑解耦
日志格式统一
返回码及注释清晰
可获取业务指标（请求量/成功率/延时）
定义关键事件
输出级别
管理方案（存放时长、压缩备份等）
当具体上述条件的日志规范得以落地，开发、运维和业务都能相应的获得较好的监控分析能力。
集中管控
运维的工作先天就容易被切割成不同的部分，发布变更、监控分析、故障处理、项目支持、多云管理等等，我们诉求一站式的运维管理平台，使得所有的工作信息能够衔接起来和传承经验，杜绝因为信息孤岛或人工传递信息而造成的运营风险，提升整体运维管控的效率和质量。
要点四：容错容灾
在腾讯技术运营（运维）的四大职责：质量、效率、成本、安全。质量是首要保障的阵地，转换成架构的视角，运维眼中理想的高可用架构架构设计应该包含以下几点：
负载均衡
无论是软件或硬件的负责均衡的方案，从运维的角度出发，我们总希望业务架构是无状态的，路由寻址是智能化的，集群容错是自动实现的。
在腾讯多年的路由软件实践中，软件的负载均衡方案被广泛应用，为业务架构实现高可用立下汗马功劳。
可调度性
在移动互联网盛行的年代，可调度性是容灾容错的一项极其重要的运维手段。在业务遭遇无法立刻解决的故障时，将用户或服务调离异常区域，是海量运营实践中屡试不爽的技巧，也是腾讯QQ和微信保障平台业务质量的核心运维能力之一。
结合域名、VIP、接入网关等技术，让架构支持调度的能力，丰富运维管理手段，有能力更从容的应对各种故障场景。
异地多活
异地多活是数据高可用的诉求，是可调度性的前提。针对不同的业务场景，技术实现的手段不限。
腾讯社交的实践可以参考周小军老师的文章“2亿QQ用户大调度背后的架构设计和高效运营”。
主从切换
在数据库的高可用方案中，主从切换是最常见的容灾容错方案。通过在业务逻辑中实现读写分离，再结合智能路由选择实现无人职守的主从切换自动化，无疑是架构设计对DBA最好的馈赠。
柔性可用
“先扛住再优化”是腾讯海量运营思想之一，也为我们在做业务架构的高可用设计点明了方向。
如何在业务量突增的情况下，最大程度的保障业务可用？是做架构规划和设计时不可回避的问题。巧妙的设置柔性开关，或者在架构中内置自动拒绝超额请求的逻辑，能够在关键时刻保证后端服务不雪崩，确保业务架构的高可用。
要点五：质量监控
保障和提高业务质量是运维努力追逐的目标，而监控能力是我们实现目标的重要技术手段。运维希望架构为质量监控提供便利和数据支持，要求实现以下几点：
指标度量
每个架构都必须能被指标度量，同时，我们希望的是最好只有唯一的指标度量。对于业务日趋完善的立体化监控，监控指标的数量随之会成倍增长。因此，架构的指标度量，我们希望的是最好只有唯一的指标度量。
基础监控
指的是网络、专线、主机、系统等低层次的指标能力，这类监控点大多属于非侵入式，很容易实现数据的采集。
在自动化运维能力健全的企业，基础监控产生的告警数据绝大部分会被收敛掉。同时，这部分监控数据将为高层次的业务监控提供数据支撑和决策依据，或者被包装成更贴近上层应用场景的业务监控数据使用，如容量、多维指标等。
组件监控
腾讯习惯把开发框架、路由服务、中间件等都统称为组件，这类监控介于基础监控和业务监控之间，运维常寄希望于在组件中内嵌监控逻辑，通过组件的推广，让组件监控的覆盖度提高，获取数据的成本属中等。如利用路由组件的监控，运维可以获得每个路由服务的请求量、延时等状态和质量指标。
业务监控
业务监控的实现方法分主动和被动的监控，即可侵入式实现，又能以旁路的方式达到目的。这类监控方案要求开发的配合，与编码和架构相关。
通常业务监控的指标都能归纳为请求量、成功率、延时3种指标。实现手段很多，有日志监控、流数据监控、波测等等，业务监控属于高层次的监控，往往能直接反馈业务问题，但倘若要深入分析出问题的根源，就必须结合必要的运维监控管理规范，如返回码定义、日志协议等。需要业务架构在设计时，前置考虑运维监控管理的诉求，全局规划好的范畴。
全链路监控
基础、组件、业务的监控手段更多的是聚焦于点的监控，在分布式架构的业务场景中，要做好监控，我们必须要考虑到服务请求链路的监控。
基于唯一的交易ID或RPC的调用关系，通过技术手段还原调用关系链，再通过模型或事件触发监控告警，来反馈服务链路的状态和质量。该监控手段属于监控的高阶应用，同样需要业务架构规划时做好前置规划和代码埋点。。
质量考核
任何监控能力的推进，质量的优化，都需要有管理的闭环，考核是一个不错的手段，从监控覆盖率、指标全面性、事件管理机制到报表考核打分，运维和开发可以携手打造一个持续反馈的质量管理闭环，让业务架构能够不断进化提升。
要点六：性能成本
在腾讯，所有的技术运营人员都肩负着一个重要的职能，就是要确保业务运营成本的合理。为此，我们必须对应用吞吐性能、业务容量规划和运营成本都要有相应的管理办法。
吞吐性能
DevOps持续交付方法论中，在测试阶段进行的非功能需求测试，其中很重要一点便是对架构吞吐性能的压测，并以此确保应用上线后业务容量的健康。
在腾讯的实践中，不仅限于测试阶段会做性能压测，我们会结合路由组件的功能，对业务模块、业务SET进行真实请求的压测，以此建立业务容量模型的基准。也从侧面提供数据论证该业务架构的吞吐性能是否达到成本考核的要求，利用不同业务间性能数据的对比，来推动架构性能的不断提高。
容量规划
英文capacity一词可以翻译成：应用性能、服务容量、业务总请求量，运维的容量规划是指在应用性能达标的前提下，基于业务总请求量的合理的服务容量规划。
运营成本
减少运营成本，是为公司减少现金流的投入，对企业的价值丝毫不弱于质量与效率的提升。
腾讯以社交、UGC、云计算、游戏、视频等富媒体业务为主，每年消耗在带宽、设备等运营成本的金额十分巨大。运维想要优化运营成本，常常会涉及到产品功能和业务架构的优化。因此，运维理想的业务架构设计需要有足够的成本意识，
小结
本文纯属个人以运维视角整理的对微服务架构设计的一些愚见，要实现运维价值最大化，要确保业务质量、效率、成本的全面提高，业务架构这块硬骨头是不得不啃的。
运维人需要有架构意识，能站在不同角度对业务架构提出建议或需求，这也是DevOps 精神所提倡的，开发和运维联手，持续优化出最好的业务架构。
(1)建立自动化运维管理平台
IT运维自动化管理建设的第一步是要先建立IT运维的自动化监控和管理平台。通过监控工具实现对用户 *** 作规范的约束和对IT资源进行实时监控，包括服务器、数据库、中间件、存储备份、网络、安全、机房、业务应用和客户端等内容，通过自动监控管理平台实现故障或问题综合处理和集中管理。例如，在自定义周期内进行自动触发完成对IT运维的例行巡检，形成检查报告。包括自动运行维护，以完成对系统补丁的同步分发与升级、数据备份、病毒查杀等工作。
(2)建立故障事件自动触发流程，提高故障处理效率
所有IT设备在遇到问题时要会自动报警，无论是系统自动报警还是使用人员报的故障，应以红色标识显示在运维屏幕上。然后IT运维人员只需要按照相关知识库的数据，一步一步 *** 作就可以。因此，企业需要事先建立自动工单式流程管理，当设备或软件发生异常或超出预警指标时会触发相关的事件，同时触发相关工单处理流程给相关IT运维人员。IT运维人员必须在指定时间内完成流程所规定的环节与工作，以提高IT运维响应问题的效率。
(3)建立规范的事件跟踪流程，强化运维执行力度
IT运维自动化管理建设时，首先需要建立故障和事件处理跟踪流程，利用表格工具等记录故障及其处理情况，以建立运维日志，并定期回顾从中辨识和发现问题的线索和根源。事实上许多实践也证明，建立每种事件的规范化处理和跟踪指南，可以减少IT运维 *** 作的随意性和强化运维的执行力度，在很大程度上可降低故障发生的概率。同时，用户还应可以通过自助服务台、电话服务台等随时追踪该故障请求的处理状态。
(4)设立IT运维关键流程，引入优先处理原则
设立IT运维关键流程，引入优先处理原则是指要求CIO定义出IT运维的每个关键流程，不仅仅是定义流程是什么，还包括要指出每个关键流程对企业有什么影响和意义。同时，在设置自动化流程时还需要引入优先处理原则，例行的事按常规处理，特别事件要按优先级次序处理，也就是把事件细分为例行事件和例外关键事件。
总之，实现IT运维的自动化管理是指通过将IT运维中日常的、大量的重复性工作自动化，把过去的手工执行转为自动化 *** 作。自动化是IT运维工作的升华，IT运维自动化不单纯是一个维护过程，更是一个管理的提升过程，是IT运维的最高层次，也是未来的发展趋势。
运维工作是本质上就是线上环境的维护，包括线上服务器的监控，数据的备份等。故应该掌握：
精通baishell/Python/Perl等1至2种编程语言
熟练掌握常用数据结构和算法，并zhi能灵活运用
熟悉网络基础知识
深入理解Linux *** 作系统
熟悉开源的监控平台工具，比如：Ganglia、Nagios等
熟练掌握Shell脚本熟悉Awk、Sed等基础工具
熟悉分布式计算或者存储系统，比如Hadoop/Hbase/Storm等
熟悉机器学习原理能付诸实践者更佳
熟悉TCP/IP、>
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）