产品运维的思考与总结

产品运维的思考与总结

做了两年的产品运维系统开发， 积累了一点经验和认识， 分享一下。

产品运维， 解决什么问题

1.   产品出现故障时， 如何快速诊断和解决问题， 快速响应客户反馈与投诉？

2.   产品运行状况是否透明是否可控， 是否能够及时预防问题的发生？

3.   产品暴露的问题中， 哪些比较棘手难以诊断， 哪些处理起来非常麻烦耗时， 哪些常常出现， 由产品的什么BUG导致， 是否可以快速修复？ 如何从运维角度发现产品的不足并推进改进？

4.   产品关键指标的统计数据， 有什么规律？ 为什么会这样？ 从中可以发现什么线索， 对产品下一步策略有什么支撑性依据？

产品运维的三个层面

1.  管理与操作层面：  产品资源与属性的信息展示与查询； 提供哪些操作恢复产品的正常使用；

2.  监控与预警层面：  产品运行的实时状况，  透明度/健康度 评估， 预警；

3.  统计与决策侧面：  通过对产品关键指标的统计， 发现规律， 更好地规划后续策略；

产品运维的具体工作

(1)   产品新特性的运维新需求。 产品新特性上线之后， 必定要对该新特性进行可用性运维， 同时要考虑与现有特性的兼容与联接。比如云磁盘上线后，对云磁盘的管理不再依附于云服务器， 需要新开一个云磁盘的管理界面，一个快照管理的管理界面， 原有的磁盘快照管理也需要进行改造， 以适应本地磁盘与云磁盘的兼容和混用。

(2)   适应项目变更，保证运维系统服务可用性。拥抱变化， 应对变化， 在产品发展过程中， 常常会进行多个项目来进行产品的改进， 这种情况下， 不会有大的关键的新特性上线， 但是会产生内部结构变更， 比如数据库变更、依赖的外部系统服务的变更、线上环境变更等。 运维开发工作必须保持对这些变更的紧密关注， 紧密跟进， 才能保证不出差错。

(3)   产品全方位监控视图及资源属性的关联管理。 一方面， 通过监控来提升产品运行状况的透明度， 使之逐渐可控； 另一方面，  需要逐步建立对产品健康度评估的标准， 能够对产品当前状态有一个基本的宏观评定。

(4)   用户体验与故障处理、工单效率提升。 运维系统的用户通常是技服、PE同学， 为他们提供有力的工具来诊断问题、解决问题， 从而更快地响应客户反馈， 对公司信誉有非常重要的间接影响力。 因此， 运维系统也需要进行仔细设计， 保证知识与操作的准确性、响应的流畅性、 操作流设计的适应性。

知识与操作的准确性， 是指技服\PE同学执行某个操作时，明确知道该操作做了什么事情，而且确实只做了这个事情，不多也不少； 响应的流畅性是指， 系统的响应必须稍快于人的操作速度和心理需求， 在该快速返回的时候不能阻塞， 在该缓的时候不要反应过敏， 导致用户误操作； 操作流设计的适应性是指， 操作流的设计必须非常便捷地切合问题的解决， 而不仅仅是提供了所需的功能， 但用户需要解决问题要多个地方跳转和切换， 影响效率。

(5)   从临时需求中挖掘问题和需求点。比如售后工程师不定时会提出一些临时需求， 这些需求往往需要快速便捷地响应， 而不能等待到发布。从重复性的临时需求中挖掘问题和需求点， 添加到运维系统的功能集中， 也是运维工作的一个重要方面。 比如， 售后工程师不时会需要获取批量云服务器的用户账号， 而当前系统中仅提供了查看单台服务器的账号信息。这可以形成一个需求点。

(6)   消除重复性的困扰。 有些功能设计不恰当会导致重复性的困扰。比如黑洞清洗操作中， 右侧显示的是该云服务器所在NC上的所有云服务器的攻击记录。 不止一次有同学反映右侧攻击记录的IP为什么跟左侧该云服务器的不一致， 会产生困惑是不是查错了。 实际上， 右侧这个显示实在应该放在 NC 视图中， 放在这里为了方便， 但给不知情者造成了困扰。

(7)   运维工作标准与检验的逐步建立。 更准， 更好， 更高效！ 这永远是运维工作的格言和座右铭。需要逐步建立一套运维标准， 来检验当前运维工作的等级。 比如， 接到问题的响应时间（不一定解决，但一定要先响应， 类似异步接口），  定位原因的响应时间， 解决问题的响应时间； 故障时长； 是否检测出产品的重要缺陷； 运维工作流程；故障处理记录与REVIEW 等；

(8)   琐碎事项的规范化处理。 经常会有一些琐碎的事情需要处理， 而且还很容易为此耗费时间。 比如， 开发需要订正数据库；  新入项目和团队需要申请各种权限等。 对于前者， 是否可以通过更好的技术来解决， 对于后者， 是否可以指派专人来进行申请， 申请人只需要提交申请哪些权限即可； 此外， 不同级别的开发/测试/技服/PE/业务支持 等角色各需要哪些权限， 是否可以有一些表格和标准可以参考， 而不是零碎地靠个人多次问询多次去完成。