U维计划启动以来，我花了将近三周的时间接触了一些公司。目前接触的企业中有银行、运营商、制造企业，其中以互联网企业居多。通过与他们的交流，我也获得了一些有价值的信息。主要是想看看运维的一些现状，分享给他们。大家分享。 1。业务互联网化让运维更重要 无论是传统行业还是互联网公司，业务互联网化都是一种趋势，一种推动力。 在传统企业中，大家都在考虑一些业态的互联网化。此时互联网+是外力，对IT敏捷性的要求也更高，这使得企业越来越重视运维，无论是从底层基础设施的维护，还是应用运维的应用运维。上面那层。全面打造IT系统的敏捷运维能力，是每个IT企业都需要关注的。有一个企业基于互联网的业务。在之前的模式中，业务部门提供需求给技术部门实现。他们彼此隔开，反应速度很慢。后来，他们以产品线为基础，建立了研发、测试、运维的垂直功能线，以保证用户需求。后续产品功能的快速响应和快速迭代。 从【优维计划】报名放出第一天，就有24家公司报名，可见大家对运维还是很重视的。 2。运维组织设置存在问题 典型问题，一是运维团队仍置于研发团队内部，导致职责不清；第二，运维团队能力定位低，只负责OS下的运维；第三种，运维团队和开发团队分离非常严重。 ****和第二种情况在互联网公司中很常见。运维的角色变成了附属。常见的运维定位是做服务器交付发布部署等，无法深入挖掘运维的价值。核心原因是研发或运维团队对运维的作用和价值认识不够。运维能做什么？有实际原因。比如他们的系统是由外部研发团队交付的，很难建立真正的运维标准；运维能力依赖第三方；基于ITIL的运维体系偏向流程；安全稳定是核心目标等。 基于这段时间的企业实际访谈，提出运维四力模型。外部力量的推动，最终需要更强的IT管控和运维驱动力。 3。大规模x86运维是挑战 在银行和运营商，x86也是一种趋势。有政策因素、技术因素和成本因素。对于他们来说，快速积累基于x86的大规模运维能力是一个挑战。 这个挑战来自两个方面。第一个方面是技术方面的。可以说，他们的运维能力在过去都是建立在高可用的硬件设备之上的。未来，他们将构建基于大规模x86集群的运营。维度能力。最好的运维体验是在互联网公司，目前的商业产品无法满足他们。他们本身不是互联网公司，缺乏对运维的实际理解。 另一个方面是组织架构的挑战。为了顺应x86运维体系，此时运维的组织架构也需要进行调整，尤其是需要增强面向应用运维的重要性，同时，一定数量的需要储备运维研发能力，满足运营管理需要。 可以说目前大部分互联网公司的运维平台和运维规范都是基于自己的运维规范，有的需要研发配合才能完成，感觉有点就像真正的练习一样。 4。运维平台的系统化能力还不够。 很多公司把运维当成一个不重要的职能角色，要么是成本中心，要么是维稳部门，要么是杂工/消防员。基于这些定位，运维自研能力严重不足，运维只能被动地基于一些开源产品构建运维自动化和运维监控能力。 运维平台的建设并不系统，更多的是碎片化的认识和工作开展。 5.DevOps已经引起了很多关注，但是还很遥远 我觉得在国内谈DevOps还为时过早。在很多公司，O的能力并没有真正建立起来。DevOps要求Dev、Test、Ops三个角色在整个产品交付周期中紧密结合，而不是割裂开来。我看到的情况大多是研发只考虑功能实现，运维只考虑一些事务性的工作，互相配合和借鉴是远远不够的。我一般是在和你沟通运维之前先提出一个要求。希望R&D能够参与进来，让他们充分了解运维，方便以后运维工作的开展。 6。互联网运维急需最佳实践指导 每个企业都在探索自己的方式，行业需要总结通用的最佳实践。 从整个行业来看，这块的成本是非常高的。以CMDB为例，每个互联网公司都在重复建设。一些传统企业，基于之前对ITIL的CMDB的理解，把一切都当做一个配置来管理，这往往会让CMDB误入歧途。比如在传统企业中，台式PC移动到哪里都需要管理，这显然让CMDB来做资产管理。 ***实践部分应该从规范、流程、意识、文化、思想、平台等多角度描述如何做好运维工作.当然，***的做法一定是有利于企业进口的。 好了，今天就到这里。 关于老王（原名王金银）：2007年加入腾讯，接触运维，经历了服务器从百台到万台的运维过程，参与运维在YY和UC不同业务形态，期间带领前端运维、数据存储运维、YY语音、游戏运维、运维研发等运维团队拥有全面的对操作和维护的理解。大力倡导互联网价值运维理念，即以用户为中心的价值由自动化平台交付，同时由数据细化和衡量。
