创业公司如何快速搭建一套可落地的运维管理体系

   当你开始运维一家创业公司的业务系统的时候，你会发现和你想象的会完全不一样,特别是从大厂毕业出来的同学,我们先简单的比较一下几个常见的大厂和创业公司的区别吧：

项目                   大厂（BAT/TMD）                           创业公司

运维体系           非常完善（起码都进入平台化时代） 几乎没有（刀耕火种时代）

基础监控           覆盖率高、完善                                 靠人肉，或者简单的脚本

管理对象           云主机/私有云                                   物理机/云主机/私有云

业务更新           业务层次清晰、更新慢                      几乎没层次、每天在不停更新

发布系统           全流程发布系统                                 人肉、简单脚本

    当你把创业公司的业务状况看完之后，很多人就开始绝望,我记得当我第一次接收上述创业公司的业务系统的时候，就非常绝望而且非常的焦虑,几乎不知道如何下手,后来经过不断的踩坑,终于总结了一套可以快速落地的方案,在此之后,接手类似的创业公司业务时,我发现再也不犯怵了，而且基本化1-2周就能快速的根据实际情况,设计一套可以落地的运维体系。

   我总结了以下一套方法（四步走）:

   第一步: 我们需要整理一张excel表格,把现在的所有服务器和服务器上运行的业务梳理一遍,这个过程很痛苦,但是非常的有效果,梳理完成之后，你就会对现在的业务现状有了非常深刻的了解,不清楚的地方可以问对应的研发,如果研发不好打交道,可以多请他们吃饭,在饭桌上问问题,通常都会很愉快的告诉你的,Excel的内容大概如下:

• 服务器内网IP：    服务器的内网IP地址,通常都是唯一的,用于标识服务器
• 服务器公网IP：    服务器公网IP地址,如果没有,就标记为None
• 部署的业务：       这个按行写入服务器上部署的不同业务信息,例如: 前端tomcat服务
• 业务部署路径:      这个按行写入服务器应用的对应的部署陆基,例如:/usr/local/tomcat
• 业务日志路径：    这个是业务应用的日志路径,例如:/usr/local/tomcat/logs

• 业务启停方法:       应用对应的启动/停止的控制方法,例如: /usr/local/tomcat/bin/catalina.sh start|stop
• 是否有监控：        标记为是/否,以便后续关注
• 业务负责人:          标记对应的业务负责人,以便后续沟通
• 代码发布方式:       根据实际发布方式,可以定义为手动发布|脚本发布等例如: 手动发布
• 关联业务调用:       根据实际情况或了解到的情况标记,这个第一次可以不用太详细,慢慢完善，目的是为了后续画出相应的架构图,例如: 调用redis中间件服务

   第二步,经过第一步的梳理，我们应该对现有业务有了一个比较深刻的了解,而且也和RD熟悉了,接下来我们需要做一个事情,使用visor或者其他的脑头软件画一张业务架构图（脑头）,根据梳理的情况和通过RD讲解的情况,我们先画一张业务架构图,通过这张图我们通常可以看出现在业务的复杂度，业务的关联关系,核心需要在图中表明一下关系:

• 用户的位置:           一定要标记用户在你的系统的位置,这样方便梳理整个业务逻辑
• 业务模块分解:      按照梳理的结果,将业务模块分类,标记到你的图上
• 逻辑上的业务模块调用关系:    用线将各个模块关系标记出来,可以用不同颜色或者不同的样式标记不同的调用关系
• 第三方系统:          如果用到了第三方系统,比如:CDN/DNS/合作伙伴系统等,我们需要特别标记出来
• 运维相关系统:      运维自己搭建的系统,一定要在图上画出来,方便做后续计划,例如:发布系统、堡垒机、网络设备等

   第三步,画好脑图后，我们需要和研发及其他相关人员确认,这一步相对简单一些,但是非常重要,我们比如把这张图完善下来,至少要完善到90%以上接近真实情况,可以继续请RD吃饭,估计需要花1周左右的时间。

[if !supportLists]l  [endif]第四步,根据完善后的脑图,我们应该可以掌控现状了,接着我们拿一张大厂的图看一看,对比一些,我们就应该知道下一步我们往哪个方向优化了,但是这里切忌直接套大厂的图,那个根本没法让你落地的,大厂花了几百人搞了好几年的体系,你想花1-2周就搞定,这个不可能的，而且现状也不允许你那么搞,肯定水土不服的,那么我们应该怎么设计可落地的方案呢？根据我的经验,这个其实是有套路的,大概的思路如下:

• 监控优先原则:      先看看当前系统有没有监控系统,如果没有,第一步一定要把监控系统搞起来，基础监控做到100%覆盖,业务监控必须覆盖到80%以上,可以考虑zabbix.
• 发布系统:            一定要有发布系统必须要有,jenkins就非常好,建议先把这个搞起来,你会发现效率至少提高一倍.
• 跳板机必须要建跳板机（堡垒机）:       必须要有,不管是安全管控，还是统一管理,这个没有什么可以说的,高级一点可以考虑用开源的堡垒机软件,简单就直接弄一台服务器,收掉其他机器的直接登录权限(特别是密码登录权限).
• 上一套配置管理系统:        ansible/saltstack挑一个吧,其他的就算了,不太容易上手,不太适合创业公司.
• 约定一个简单的流程:        这一步及其关键,和RD、QA一期定一个简单的上线发布流程,没有工单系统的情况下,建议邮件审批,所有上线的项目必须有人为其负责,要不从何谈稳定呢？

    相信经过四步走以后，我们应该可以快速的得到一个可落地的运维体系实施方案,接着我们就可以按照这个规划进行落地,再根据落地情况进行微调,按照我的经验,一般四步走到完全落地大概需要1个月或者1个半月的时间,等这套体系运行稳定了,接下来就可以做更深入的运维改造设计了,比如: 规范化、从脚本化过度到平台化、智能化等,还有就是稳定性方面的建设,比如: CAP改造、异地多活、降级、故障演练等,这些后续再介绍吧，后面我再以一家公司的例子介绍一下这块吧,希望这个对大家有所帮助。