嘉宾介绍：陈奕泰，凡客诚品系统运维部高级经理。目前在凡客诚品从事运维工作，负责IDC机房和网站业务的技术运营，以及企业内部IT系统和网络运维。从事IT基础架构工作十余年。曾在武汉微软技术中心为各行业、中小企业做IT规划建设。后加入凡客诚品，全程深度参与公司系统和网络基础建设。简介作为企业IT的主要技术负责人，在逐步建立支撑全国数万员工的企业IT系统的过程中，互联网运维、企业IT运维、外网和内网,以及甲乙双方的关系对IT技术应用和管理实践的深刻理解。下面说说我在运维管理或者企业IT管理上的粗浅想法和具体应用。我是如何看待过去的运维工作的？听腾讯刘启彤说，运维就是技术操作。我觉得很好。伟干的工作是打理一堆网络设备、服务器、各种操作系统和应用软件……让它们高效、安全、稳定地运行。对于运维来说，汗流浃背地把服务器扛上架是常有的事。他说这话的时候，我想到了网站运营、企业运营、某大项目运营……反正我觉得“运营”这个词比较大方。这让辛苦了许久的运维汗水都抖掉了，似乎还得意洋洋。我也需要有超然的心态去面对运维工作的简单分类和重复单调的工作。只有跳出自我，才能更好地完成本职工作。运维是一个比较单调的工作。按照技术分类，运维包括机房管理、网络管理、系统管理、数据库管理和各种应用系统管理。从管理的角度来说，不管是哪一种技术，我把运维按照处理的特点分为两类，比如周期长短、量大事小、每天重复、紧急等。一种是日常（类）运维，一种是项目（类）运维。我的分类源于我在五六年前的PMP培训过程中的感悟。PMPBOOK书中有一段话：“项目源于有组织的人类活动。随着人类社会的发展，有组织的人类活动逐渐分为两种：一种是连续的、反复发生的活动，称为“工作”或“作业”，如企业流水线上生产大量产品活动;另一种是临时性的、一次性的活动，人们称之为“项目”（project）。日常运维是属于***范畴的活动。从稍微大一点的角度来看，我们整个运营维度的工作可能连算是一个项目。但是怎么把重复做的工作变成一次性的呢？还记得你上学的时候讲微分的概念吗！怎么求微分？这两个问题看起来很奇妙Sparks有已经生成了。通过微分，我们可以把一个曲线函数看成是一段直线，这样我们就可以推导出来。什么是项目运维？在实际工作中，是否可以微分一个连续的工作？波浪式的工作分成项目？我觉得是可以的。通过对不同阶段的任务或者周期性的任务进行切割协调，一个周期性的运维可以拆分成几个小的项目。整个运维n通过微小项目的管理建立维护工作体系。微型项目的管理也称为基于任务的管理。这种基于任务的管理可以帮助我们缓解长期容易疲劳的运维工作。并且还可以形成一个快速迭代的系统，让方法更加灵活，注重交付结果的同时也关注过程。让我们用下面的几个例子来说明。在一个几十人的运维团队中，我们实际是根据会议沟通和日常工作来实现对分类的理解：运维分类进一步解释日常运维是我们运维人员的工作内容日常生活中经常打交道。例如：系统运维人员处理某服务器某目录磁盘空间不足的问题；添加或修改DNS域名A记录。机房人员更换故障硬盘。网络人员查看某条带宽异常的出口线路流量。”。项目运维是非日常运维的内容，大到包括IDC机房或办公楼的系统网络建设，小到升级系统内核，因为涉及重要和关键业务，或者因为技术升级过程，比较繁琐，需要考虑的方面很多，也会包含在非日常运维中，需要注意的是，团队在日常运维中遇到一些故障，maintenance.快速解决后，在经常出现的统计中会发现类似的现象，总会被作为需要解决的问题提出来。不管是理论意义上的真实项目，还是有问题的项目，或者其他具有项目特点的东西，只要在日常运维范畴内不能快速归纳，都会被认为是一个项目。这里指的是一个项目的特点，要处理的事情很多，范围很广，成功完成后从无到有，影响深远。也是像项目一样规划的，周期比较长。可能还会涉及更多的资源和人员。具体的其他特点，可以参考项目管理方面的书，但不能生搬硬套。所以我个人认为，以项目管理的方式来实施和推广这样的东西是非常合适的，这也是为什么叫项目化运维的原因。总之，通过综合处理各种运维事物的共性，做了一个二分法，日常运维和项目运维。非此即彼，很容易分。如何立项？在实际操作中，由于没有明确的定义，普通同事很难掌握。但既然是项目，立项还是有门槛的。这个项目能不能批下来，还需要几个人商量一下再决定。但是这几个人是怎么判断的呢？答案当然是，不是所谓的任期立项委员会。实际工作中，团队的例会就足够了。毕竟负责各个技术方向的高管都是技术出身，能够很好的把握方向。例如：我们在日常运维中发现某路由器的CPU总是高，连续多次触发告警，在日常运维中可以通过分流来缓解。但实际报警时，流量负荷并未达到装置的设计上限。初步推断知道还需要更深入的调查。这个时候谁来启动这个项目？通常，网络管理员会在定期的工作报告中报告这个问题，希望将其推广到一个项目中，找到问题的根源。当然，这种情况也可能是他主管的原因，在日常的运维处理报表中发现这个事件经常发生，希望升级为一个项目。另外，服务器系统管理员可能最近发现有些服务器或者应用网络延迟非常大，然后发现这个问题比较严重，所以在运维部的高例会上立项。不管是哪个，在内部技术周期例会上，或者在运维管理会议上，都会对这些情况进行分析，对业务的影响程度和主要解决这个问题的技术类型进行粗略的评估，并且确定项目和负责人。项目目标以及开始和结束日期。项目工作流程如何？假设在网络组内部会议上讨论了这个问题，那么这个项目将通过网络组内部组织人员来解决。在后续处理过程中，如发现需要涉及线上业务的正常运行，可能需要机房团队和系统团队的协助。甚至问题的根本原因可能在系统组负责的服务器上，然后项目将升级到更大的团队级别。但是升级就是升级，一般习惯是不换之前设立的projectleader，除非特殊，否则不会换。在这个过程中，管理层可以做更多的事情来协助项目负责人，尤其是负责人的直接主管。我觉得这对于培养团队成员的综合技术素质，提高整个团队的协作能力是非常有益的。如何实施运维工作？由于运维工作分为日常运维和项目运维，因此可以分开实施。基本原则是在思想上认清每项工作的意义，并有条不紊地执行到位。实现它的最佳方式是将想法和系统技术化。通俗地说，“技术化”就是通过各种软件系统对运维工作进行管理。打个形象的比方：我们日常开车，需要有高度的安全意识（思想层面），当然需要制定交通法规（制度性的）来指导我们的行车，会设置各种车道在路上。比如实线和虚线，马路中间的实线是不能被碾压和越过的，高速公路上的实线也设置了又高又厚的水泥围栏。这个水泥围栏是意识形态和制度技术的极端体现。.实线无法阻止不守规矩的汽车，但混凝土围栏可以！所以想法需要以文档的形式固化，而当文档最终需要通过技术实体的软件系统来固化，帮助我们更正确的工作。有了体现思想的系统和软件系统，最重要的是：用它，天天用它。另外，并不是所有的文化思想都能固化，需要培养和交流。这些无形的和有形的东西需要被谈论，他们需要每天以不同的方式被谈论。当然，思想文化、文件系统、系统软件不是一天就可以完善的，完善了也不能高枕无忧。他们需要集全民智慧，与时俱进，不断进化。因为开放、向上、探索本身应该是一个好的运维团队的文化内核之一。如何做好日常运维工作？对于日常的运维来说，这种东西就是运维的主要工作。虽然琐碎，一般技术含量不高，但极大影响客户（外部用户和公司同事）的用户体验，影响运维团队。提供的服务质量。ITIL中的事件管理系统帮助我们管理日常的运维工作。基于ITIL的IT服务管理思想，结合自身业务情况，公司开发了一套事件管理系统。个人觉得这个系统最有意义的地方有两个：1.对接各个团队或者部门的服务。用户可以根据自己选择的事物类别，被系统分配到最合适的团队去处理。其原理是每个团队都提前准备好自己工作职责的菜单，用户可以根据自己的需要“点菜”。例如上海办公室的用户使用Outlook出现问题，可以在事件管理系统中进入outlook，找到与Outlook相关的服务项，选择提交，系统会分配给IT桌面支持团队在上海根据用户账户中的属性。当系统也分配错误时，受让人可以将用户转移到认为正确的团队......我什至认为这个系统应该推到公司所有部门使用，而不仅仅是限于技术中心.2.服务质量控制技术化。根据重要情况对用户的问题进行分级。不同的年级有不同的初始响应时间。如反应不及时，后续处理不及时，将上报处理。并不是说不重要的事情就变得重要了，而是不管是哪种事情，如果反应不及时，都会被报告给事件处理者的领导，甚至是领导的领导。当然，还有相关的统计报表统计个人和团队事件处理的数量和质量。所以不管是个人还是集团部门，都好像背后有鞭子在飞。如何做好项目运维工作？对于项目运维来说，这种事情一般涉及面比较广泛和深远，是重中之重。在实践中，我通常用项目运维之类的东西来监控长期的事情，比如部署某个系统，或者作为问题管理。基本上是运维部门内部的事情，或者已经转化为内部的事情了。因为用户少，而且只面向运维部门，所以我们直接使用开源的Redmine作为管理软件。Redmine非常灵活。您需要了解它是基于任务（问题）的。至于怎么用，需要结合标签来做。我不会详细谈论它。有兴趣的可以慢慢探索。通过该软件系统，可以弥补事件管理系统的不足。那么事件管理的短板在哪里呢？主要缺点是事件管理最（只）适合于管理单一的、分散的、短期的、快速的事物。而project类的东西需要拆分成N个子任务，任务之间也有依赖关系等等。另外，项目类的运维周期有时会很长。如果这么长时间不处理，记录在事件管理系统里，那你的KPI就完了。-_-|||通过项目管理软件，我们实现了扁平化管理，可以查看所有进行中的任务，可以细化下面的子任务。这样跟领导汇报的时候就不会被蒙蔽了，跟组员交流的时候也容易就事论事。一般来说，子任务是项目负责人和任务受托人通过相互沟通协商确定的，最终完成工作的人有很大的自主权。***实践中，在不影响上级任务目标的情况下，赋予子任务实施者更大的自主权，比如自己定制详细的任务目标，有助于调动当事人的主观能动性，因为他是在完成自己的任务目标。运维用数据说话，因为运维工作分为日常运维和项目运维，分别受到事件管理系统和项目管理系统的监管。有了好的运维管理平台，现在基本上整个运维团队的工作都已经普遍数字化了。同时，作为一般的运维人员，两者也是一个很好的知识交流平台。工作好不好，不是领导决定的，而是日常运维和项目运维中的表现。计算。这样一来，作为运维管理者，他们也有了管理工具，团队的绩效也有了数据。以上写在***的观点和做法是我个人的看法，纯属交流，每个人都有自己的管理经验，个人觉得只要符合自己公司的实际情况，运行顺畅无任何障碍，都是很好的途径和方法。好的方法和方法总有普世智慧的光芒，希望能给大家提供一些参考价值。
