【简讯】看运维下菜做软件
前言
这是个技术探讨性简讯，非技术订阅用户请忽略本次推送。
我维护过传统商业软件、开源linux软件、云平台软件，我也主导改造过一些服务软件，所以我总结了一下做服务端软件（比如私有云、大数据平台）怎么才能和运维团队配合。
一个软件先要了解自己的用户，运维团队要做能力和工作量分层的，我将其分为了三大类，希望大家能参考这个角度设计好产品说明文档。
第一部分. 一线运维负责维持现状
每个公司都有一批运维干盯监控等重复性工作，如果一线运维要接手一项陌生服务，需要了解下列几点：
1. 服务叫什么名字；这关系到多方沟通的准确性。
2. 服务用途做个一句话说明；软件的名字就像人名一样，记住了软件的名字，也要知道软件对应的“相貌”。
# 比如：dbcache-crm，这是CRM系统做读查询时的访问代理和缓存资源池，由前端应用做读写分离和IP轮询，业务容忍5分钟的旧缓存。这就是一个很棒的服务名和软件解释。
3. 做好监控和故障描述；运维要知道业务是否正常，不正常了如何下一步操作。
4. 重启后能恢复服务；服务级故障总要有个快速恢复的方法，重启是最简单的。
# 运维不介意操作步骤繁琐，但要求过程清晰结果可控。如果重启也不能恢复单点服务，那说明这是个alpha版程序；对于群集来说，单点程序重启就是删除和新增节点，这更是常规操作。
5. 备份的目标；有效的备份可以恢复环境和业务，还能当做快照分析。
# 注意备份不是恢复，新手能用备份恢复业务是软件的功劳，不是他的工作能力。
一线运维的工作目标是：让事情不会因他而变坏，让常规故障可控快速恢复，给高级运维人力减负。
第二部分. 高级运维负责操作和排障
高级运维比一线运维有了更强的判断和操作的能力，高级运维的关注点变了：
1. 紧急故障的频率和恢复速度；他们开始为稳定性结果负责，报警吓醒的都是他们。
2. 例行维护的频率和繁琐程度；有些维护工作需要权限判断，有些维护工作需要技术判断。
3. 单一服务的搭建和恢复能力；他们对于单一服务的搭建和备份后恢复有完整的技能掌握。
# 平台搭建不是常规操作，且可能是原厂支持或者上一代同事来做，相比之下单一服务的重构会比较频繁。
4. 业务日志分析能力；高级运维通过观测日志来了解业务状态，为排查业务类而非平台类故障做好准备。
5. 编写常规操作文档/脚本；结合自身的业务以及软件功能，高级运维可以将一些快速例行操作文档化和脚本化。
6. 平台业务带伤恢复能力；某些意外的故障是要断腕式恢复业务的，根本没开会和试验的时间，就是要运维快速判断。
# 常见的是保数据一致性还是保业务持续性，优先恢复哪些重点模块，禁用哪些麻烦服务等等。
7. 原厂/社区沟通能力；运维和原厂沟通，要求清晰描述故障，还要评估原厂方案的靠谱性。
# 即使商业原厂服务，他们能保证的是限定环境下限定操作的可靠性，不可能了解平台业务状况和为客户业务负责。
高级运维的工作目标是：故障的伤害到我为止，业务的部署自我开始，要给一线运维做复杂度减负。
第三部分. 资深运维关注内部运营和业务融合
资深运维其实分为两类，技术方向的架构师和资源管理方向的总监。他们未必能处理具体故障，但关注高度值得认可：
1. 平台稳定性和搭建维护成本；这是软件选型采购，以及IT团队对公司业务承诺的重要考核依据。
# 如果这是个云计算平台或物理机资源池，合理压缩研发和业务团队的IT开销也是重要工作。
2. 平台业务承载量；这是帮整个IT团队摸清楚公司业务状态，并给高管层做技术决策支撑。
3. 组件逻辑图和业务逻辑图；我们需要将各个服务的上下游依赖关系和所有业务逻辑的访问流程图画出来。
# 有了这些图，高级运维分析业务和处理故障才不会变成瞎子。
4. 研发和业务部门理解和融入运维架构和流程；这是一个宽泛但重要的团队合作概念。
# 运维是研发和业务的支撑部门，前端给支撑的合理减负，能让运维省力省钱省心。运维有什么新能力，比如云平台支持快速部署高精度监控等等，都需要研发甚至业务部门共同配合才能发挥出政绩。
资深运维的工作目标是：平台稳定由我掌握，部门利益由我代表，帮基层运维做责任减负。
总结
凡是服务端软件都离不开运维工程师，交付质量和业务稳定性也要靠系统运维来体现。企业级软件要商业化推广，要做技术培训认证体系，就要理解运维工程师的工作逻辑和真实需求。
# 私有云软件算服务端软件的范畴，IaaS公有云其实是个无法维护的软件服务，而大客户一样有查日志和调接口的特型需求。
写这段文章的目的，主要是希望新兴云厂商和软件厂商认真考虑，你们做的软件是否真的让运维用户满意；如果对方不满意，那客户的诉求是什么，是软件功能不达标，还是培训和维护不到位。
# 举个例子，“易于安装”和“易于重装”不是同一个概念，“易于安装”便于新品测试，而运行中的平台要的是“易于重装”。
# 再举个例子，从稳定性角度看肯定希望资源利用率越低越好，而从成本角度看资源利用率是希望越高越好的，哪些资源可以超卖，哪些资源严禁售罄，这是需要客户掌握的。
研发和运维是孑然不同的工作逻辑，企业软件研发很难理解运维用户的工作逻辑和诉求，我自认为是合格的运维工程师，希望能把这一段认知差异补齐。