摘要：
网络运维基础知识？什么指标衡量验证完整性？如何进行全面的运维管理工作？网络运维基础知识？网络运行维护，包括网络设备管理（计算机、服务器等）、操作系统维护（系统打补丁、系统升级等）、... 网络运维基础知识？
网络运行维护，包括网络设备管理（计算机、服务器等）、操作系统维护（系统打补丁、系统升级等）、网络安全维护（***防范等）。
网络运维是IT管理的核心和重点部分，也是内容最多、最繁杂的部分，该阶段主要用于IT部门内部日常运营管理，涉及的对象分成两大部分，即IT业务系统和运维人员，该阶段的管理内容又可细分为七个子系统：
应用/服务管理：对各种应用支持软件如数据库、中间件、群件以及各种通用或特定服务的监控管理，如邮件系统、DNS、Web等的监控与管理
数据/存储/容灾管理：对系统和业务数据进行统一存储、备份和恢复
业务管理：包含对企业自身核心业务系统运行情况的监控与管理，对于业务的管理，主要关注该业务系统的C***（关键成功因素Critical Success Factors）和KPI（关键绩效指标Key Performance Indicators）
目录/内容管理：该部分主要对于企业需要统一发布或因人定制的内容管理和对公共信息的管理
资源资产管理：管理企业中各IT系统的***资产情况，这些***资产可以是物理存在的，也可以是逻辑存在的，并能够与企业的财务部门进行数据交互
信息安全管理：该部分包含了许多方面的内容，目前信息安全管理主要依据的国际标准是ISO17799，该标准涵盖了信息安全管理的十大控制方面，36个控制目标和127中控制方式，如企业安全组织方式、资产分类与控制、人员安全、物理与环境安全、通信与运营安全、访问控制、业务连续性管理等。当然，以前瑭锦的老师说网管也可以算半个运维。
什么指标衡量验证完整性？
从广义角度讲，测试覆盖率主要分为两大类，一类是面像项目于的需求覆盖率，另一类是更偏向技术的代码覆盖率。
需求覆盖率
测试对需求的覆盖程度，通常是将每一条分解后的软件需求和对应的测试建立一对多的映射关系，最终目标是保证测试可以覆盖每个需求，以把证软件产品的质量。
我们通常***用 ALM，Doors 和 TestLink 等需求管理工具来建立需求和测试的对应关系，并以此计算测试覆盖率。
需求覆盖率统计方法属于传统瀑布模型下的软件工程实践，传统瀑布模型追求自上而下地制定计划、分析需求、设计软件、编写代码、测试和运维等，在流程上是重量级的，已经很难适应当今互联网时代下的敏捷开发实践。
所以，互联网测试项目中很少直接基于需求来衡量测试覆盖率，而是将软件需求转换成测试需求，然后基于测试需求再来设计测试点。
如何进行全面的运维管理工作？
我所指的IT运维，是软件生命周期的最后一步，程序开发、测试完毕后的工作，都是由运维人员来完成的。工作内容主要是：硬件、基础设施的部署（OS\DB\MW等）、程序的上线、程序的例行维护（重启、日志清理、高可用演练、备份等等）、应急恢复、监控、版本更新、容量分析、扩容等等。这些都是为了保障程序能够顺利、安全、稳定的运行，不要出岔子，万一出问题，保证7*24小时的应急处理，直至恢复。
运维的汇报对象当然是你的领导了，你的领导也是运维，只不过级别更高。运维是不会向开发、测试或其它角色汇报的。你的领导只是负责更多的系统或者承担更大责任的运维人员。
其实从运维的工作内容也可以看出，运维最重要的指标是系统可用率，比如说建行的重要系统，要求可用率达到5个九，就是达到99.999%的可用率，一年出现异常停止的[_a***_]，也不能超过几个小时。所有系统都有自己的RTO\RPO，应急恢复是运维的重要工作之一。出现故障时，你能不能第一时间把它恢复起来，完全体现了你的水平。
有些人，可能觉得运维没什么技术含量，这可能是误解了。真正的运维高手，还是很有水平的，能够救系统于水火之中，犹如江湖救急，大侠在世。高手是充分掌握了基础设施各层级的特性、对系统应用也了如指掌的人，犹如打通了任督二脉。曾经在工作中亲眼见证过的重大应急过程：银行某系统异常，无法对外提供业务，此时已过9点，网点都已开门，每分钟都在接受顾客投诉。IBM的专家和行内高手都在应急处理，二者在应急策略上产生冲突，争执不下。老总坐镇，凭着对行内高手的一贯信任，一声令下，就按他说的做，几分钟后，高手在系统前一阵忙碌，系统重启成功，顺利恢复业务。这又记录了高手在行内的一大战功。
干什么工作，都有前途、都会培养能力，区别就在于抱着什么态度去做、坚持去做。见证了身边的许多乌鸦变凤凰的过程。分享一些经历，也与大家共勉。
