服务器运维组织搭建

服务器运维组织搭建我做服务器运维相关工作快十年了，从初创公司几个人的小团队到上万人企业的运维部门，见过太多让人哭笑不得的状况：有的公司业务做到几个亿规模，运维还是只有一个人全年24小时待命，服务器崩了连夜爬起来赶路去机房，累出胃病还落不着好；有的公司照搬大厂架构，招了一堆细分岗位，人浮于事，出了问题互相踢皮球，最后故障处理速度还不如小团队快。这么多年踩坑踩下来我最深的感受就是，服务器运维不是找几个人看服务器就行，搭建一套适配自身业务的运维组织，才是业务稳定运行的根本保障。本文我就结合自己的实际经验，从前期准备到架构搭建再到后续优化，完整讲清楚服务器运维组织该怎么搭。1服务器运维组织搭建的前置准备很多人一上来就想着招人定岗画架构图，其实不对，动手之前必须先把基础问题理清楚，不然搭出来的组织肯定水土不服，没法适应自身业务的需求。1.1明确组织的核心目标与定位做任何组织搭建，第一步都要想清楚我们要这个组织干什么。服务器运维组织的核心目标，总结下来其实就是三件事：第一是保障业务连续性，说白了就是尽量让服务器不宕机，就算出问题也能快速恢复，不让核心业务受大面积影响；第二是控制运营成本，不管是物理机还是云服务器，不合理的资源占用就是白白浪费钱，运维要做的就是把资源用在刀刃上，省下来的就是纯利润；第三是保障安全合规，现在不管是什么行业，数据安全、网络安全要求越来越高，一旦被攻击丢了数据，轻则罚款重则直接影响企业经营，合规这块也绝对不能出问题。除了目标，还要明确组织的定位，这个一定要结合公司的发展阶段来定：初创小公司，运维组织就是核心支撑部门，要能快速解决所有和服务器相关的问题，不能拖业务的后腿；中型企业，运维组织要从单纯的支撑转向效率提升，通过标准化和自动化减少重复劳动，释放更多人力做更有价值的事；大型集团企业，运维组织要成为价值中心，不仅要保障稳定，还要通过架构优化给业务创新打基础，降低业务创新的技术门槛。我之前待过一家创业公司，老板一开始把运维定位成“后勤打杂”，工资开得低，也不重视，结果一次核心数据库被误删，运维一个人忙了十几个小时才恢复，耽误了关键的业务上线，损失了好几个大客户，后来才重新调整定位，补上了人手，这就是一开始定位错了的深刻教训。1.2梳理现有资产与业务需求定位明确之后，就要摸清楚自己的家底，不然怎么知道要多少人，要怎么分工？首先要梳理清楚现有服务器相关的所有资产：一共有多少台物理服务器，多少台云服务器，存储容量有多少，网络带宽是多少，这些服务器都跑了哪些业务，哪些是不能出问题的核心业务，哪些是可容错的边缘业务，核心业务的峰值流量是平时的几倍，每年有没有固定的大促、活动时段，这些都要一条一条理清楚，不能大概估摸。然后还要梳理清楚业务端的需求：开发团队每周要发几次版，要不要运维配合做环境部署和灰度验证？业务有没有硬性合规要求，比如金融行业要过等保，医疗行业要过数据安全测评，这些都需要运维投入专门的人力去推进，不能等要审核了才临时抱佛脚。我每次帮朋友搭运维团队之前，都会让他们先花一周时间把这些理清楚，曾经有个做电商的朋友，一开始说自己业务不大，只要两个运维就行，结果梳理下来才发现他们有六个业务线，每年三次大促，核心峰值流量是平时的十倍，还需要做三级等保认证，两个人就算不睡觉也根本扛不住，最后调整成了五个人的分工团队，后来大促的时候果然稳得住，没出什么大问题，这就是梳理清楚需求的好处。1.3确定组织搭建的核心原则理清楚目标和家底之后，还要记住几个核心原则，避免走歪：第一个是适配性原则，有多大锅下多少米，不能盲目照搬大厂的架构，小公司非要搞七八个人的细分团队，就是纯粹的成本浪费；第二个是权责清晰原则，每个岗位谁管什么，出了问题找谁，一定要说清楚，不能模糊，分工模糊是出问题后互相推诿的根源；第三个是安全优先原则，任何分工流程都要把安全放在第一位，不能为了赶进度提效率就牺牲安全；第四个是人性化原则，运维这个工作性质就是需要24小时待命，经常要熬夜加班，搭组织的时候一定要考虑到成员的承受能力，不能拿人当机器用，这一点我感触特别深，团队成员状态舒服了，才能干好活，硬扛早晚要出问题。做好了前期的准备工作，我们就可以进入实质的架构搭建和岗位设置环节了，这一步是组织落地的核心，要根据自身的业务规模量体裁衣，不能生搬硬套别人的方案。2服务器运维组织的架构分层与岗位设置根据不同的业务规模和服务器体量，我们可以分成三种常见的架构模式，每种模式对应不同的岗位设置，都能满足对应阶段的需求。2.1按照业务规模适配的架构模式2.1.1小型团队/初创公司架构一般来说，服务器总量在五十台以内，业务线不超过三条的初创公司或者小型企业，适合用1-3人的全栈运维小组架构，不需要细分岗位，所有人都要覆盖所有运维工作，从服务器采购上架、环境部署、日常巡检、故障处理到安全备份，全都覆盖。这里要提醒一句，很多初创公司为了省钱，让开发兼职做运维，这个真的不建议，开发的核心精力是做业务开发，运维的很多工作是需要长期盯防的，兼职很容易出疏漏。我之前认识一个开公司的朋友，为了省每个月一万多的运维工资，让两个开发兼职管服务器，结果三个多月没打系统补丁，被黑客入侵加密了核心数据，最后花了几十万赎金才解出来，算下来比找十年专职运维都贵，真的得不偿失。哪怕只有一个人专门做运维，也比兼职靠谱得多。2.1.2中型企业/多业务线架构当服务器总量超过五十台，业务线开到三条以上，年业务规模过亿的时候，就需要拆分专业小组了，一般分成三个小组就够用：第一个是基础运维组，负责所有服务器底层的资源管理，包括物理机硬件维护、云资源的采购调配、网络配置、机房管理这些基础工作，是整个运维团队的大后方；第二个是业务运维组，按照业务线对接，每个业务线配一到两个专人，负责对接开发和产品，做业务的环境部署、发版支持、性能优化、业务故障处理，相当于业务线和运维之间的纽带；第三个是安全运维组，至少配一个专人，哪怕人手不够让一个人兼职，也要专门管这块，负责漏洞扫描、入侵监测、数据备份、合规认证这些工作，现在网络攻击越来越多，这块真的不能省。这种拆分之后，每个人只负责自己熟悉的一块，效率高很多，出问题也不会找不到责任人。2.1.3大型企业/集团化架构如果是服务器几百台上千台，业务线十几条甚至几十条的大型企业，那就需要更细的分层架构了。除了上面说的基础、业务、安全三个组之外，还要加两个核心团队：第一个是运维架构与自动化团队，负责整个运维体系的架构设计，开发自动化运维平台、监控告警平台，把原来手工干的活都自动化，解放人力提升效率，这个团队是提升整个运维团队效率的核心；第二个是专职值班响应团队，专门负责7*24小时的故障接警和初步处理，原来都是各个组轮值，大家休息不好，专职轮值之后，其他团队的人不用天天盯着手机，可以安心做项目，故障响应也更专业。这种架构看起来人多，但是对于大业务量的企业来说，反而成本更低，因为出一次大故障的损失，比养一个团队一年的成本都高。2.2各岗位的核心职责与能力要求架构定好了，每个岗位的职责和能力要求也要说清楚，避免招错人、用错人。2.2.1基础运维岗核心职责就是管理好底层服务器和网络资源，做好日常巡检，硬件故障更换，资源弹性调配，给上层业务提供稳定的基础环境。能力要求不需要太高端，只要熟悉主流的Linux系统操作，会配置常见的网络服务，动手能力强，做事细心就能干，适合刚入行没多久的新人来做，慢慢积累经验。2.2.2业务运维岗核心职责是对接业务线，保障业务从测试到上线全流程的服务器环境稳定，协助开发做性能优化，处理业务相关的各类故障。能力要求除了懂运维基础，还要能听懂业务语言，会和开发产品沟通，最好懂一点基础的开发知识，能看懂基础的业务代码逻辑，这样出问题能快速定位，这个岗位是最考验综合能力的。2.2.3安全运维岗核心职责是做好服务器安全防护，定期扫描修复漏洞，应对入侵攻击，做好数据备份和恢复，配合公司完成各类合规认证。能力要求需要熟悉常见的安全漏洞原理，会用主流安全工具，了解基本的合规要求，细心而且有责任心，因为安全这块都是防患于未然，很多工作做了大家看不到，不做就出大事，所以责任心特别重要。2.2.4运维管理/架构岗核心职责是规划整个运维体系的发展方向，制定工作流程，协调团队资源，带领团队完成目标，对于架构岗来说还要负责技术选型和架构优化。能力要求不仅要懂运维全流程的技术，还要会管人，能站在公司业务的全局角度想问题，不能只盯着技术本身。这里我也说一句掏心窝子的话，招这个岗不一定非要找大厂出来的顶尖专家，适合自己公司的才最好，我之前见过一家中型公司，花高薪挖了一个大厂的运维架构师，人家天天想着做高大上的分布式架构，结果公司现阶段最需要的是把日常故障处理和备份流程理清楚，最后人家干了半年觉得没意思走了，公司还耽误了大半年时间，这个教训一定要记住。架构和岗位都搭好了，不代表组织就能正常跑起来，接下来还要建立完善的运行机制，不然就是一堆人摆在那，还是一盘散沙，发挥不出应有的作用。3组织运行机制与文化建设一个好的组织，三分靠架构，七分靠运行，机制和文化对了，团队才能发挥出最大的威力。3.1建立标准化的工作流程运维这个工作，最怕的就是随意操作，所以一定要把所有常见工作都做成标准化流程，所有人按照流程来，就能减少80%的人为故障。3.1.1日常运维流程日常的巡检、备份这些基础工作，一定要定清楚标准：核心服务器每天巡检一次，边缘服务器每周一次，巡检要查哪些内容，记录要存在哪里，都写清楚。尤其是备份，一定要定好定期验证的流程，我自己早年吃过一个大亏，一次核心服务器硬盘损坏，我想着有备份放心得很，结果恢复的时候才发现，备份任务半个月前就因为存储满了失败了，没人去看运行日志，最后丢了两天的核心数据，赔了不少钱，从那之后我不管在哪搭团队，都要求备份必须每周抽一个人抽查验证，做一次恢复测试，确保备份是可用的，这个真的是血的教训。3.1.2故障响应与处理流程要先给故障分好级，一级故障就是全公司核心业务全面瘫痪，这个要触发最高级响应，五分钟之内通知到所有相关负责人，半小时之内必须有人牵头处理，处理完24小时之内出复盘报告；二级故障就是部分业务出问题，不影响核心，那就是对应负责人一小时之内处理，一周之内出复盘。流程定清楚，出故障的时候大家就不会慌，不会你推我我推你，都知道该干什么。3.1.3变更管理流程行业内统计，至少70%的线上故障都是变更引起的，所以变更管理流程一定要严：所有变更必须提前申请，说清楚变更内容、影响范围，必须提前做好回滚方案，必须避开业务高峰，核心变更必须有两个人复核，不能一个人私下改线上配置。我见过太多人觉得自己熟，半夜偷偷改个配置，结果出问题回滚不了，把整个线上搞崩，这样的例子真的太多了，所以流程定了就要严格执行，谁都不能例外，哪怕是技术主管也不行。3.2建立合理的考核与激励机制运维这个工作很特殊，没故障的时候大家觉得你没干活，出了故障第一时间找你背锅，所以考核和激励一定要合理，不能寒了大家的心。考核不能只看出不出故障，还要看你做了多少优化，降了多少成本，提升了多少效率，比如某个运维写了个自动化脚本，把原来每天两小时的巡检工作变成十分钟，给大家省了好多时间，这个就要算成绩，不能说没故障就是应该的，出故障就要扣钱。激励这块更要人性化，熬夜值班要有额外的补贴，值班之后必须给调休，逢年过节值班要给双倍三倍工资，平时出故障加班处理完了，也要给调休或者补贴，我之前待过一家公司，原来值班一晚上只给五十块补贴，还不让调休，大家天天怨声载道，告警响了都故意晚几分钟接，后来改成一晚上补一天调休加两百补贴，大家的积极性一下子就上来了，响应速度快了好多，钱真的要花在该花的地方。3.3团队文化建设运维工作压力大，24小时手机不敢关机，很多人干久了都会有倦怠感，所以团队文化特别重要。首先要推老带新的文化，新人进来之后，给安排一个老员工带，不要让新人自己摸瞎，很多新人刚进来遇到故障就慌，有老人带就会稳很多。然后要定期做技术分享，每个星期抽一两个小时，大家讲一讲最近遇到的故障，怎么解决的，每个人都能从别人的踩坑经历中学到东西，比看书管用多了。最重要的是要建立“对事不对人，故障归零”的文化，出了故障先解决问题，先找流程和系统的问题，不是上来就追责骂人的，要是一出问题就骂人，大家以后出了小问题就会藏着，最后拖成大故障，反而更糟糕。只要不是故意违规，出了问题一起改，避免下次再犯就行，这样大家才敢放开手脚干，有问题也会主动说。组织搭好运行起来之后，也不是一劳永逸的，业务在发展，技术在变化，组织也要跟着不断迭代优化，才能一直适配业务的需求。4组织搭建后的持续迭代优化服务器运维组织不是一个一成不变的架构图，是要跟着业务一起成长的动态体系。4.1定期评估组织适配性我一般建议每半年评估一次，现在业务发展快，半年时间服务器可能从几十台变成几百台，业务线从两三条变成十几条，原来的架构和人手就不够用了，要是不及时调整，就会把人累垮，还容易出问题。比如原来三个人的全栈团队，业务翻了三倍，还是三个人，每个人都连轴转，肯定会有疏忽，