做了两年的产品运维系统开发, 积累了一点经验和认识, 分享一下。
产品运维, 解决什么问题
1. 产品出现故障时, 如何快速诊断和解决问题, 快速响应客户反馈与投诉?
2. 产品运行状况是否透明是否可控, 是否能够及时预防问题的发生?
3. 产品暴露的问题中, 哪些比较棘手难以诊断, 哪些处理起来非常麻烦耗时, 哪些常常出现, 由产品的什么BUG导致, 是否可以快速修复? 如何从运维角度发现产品的不足并推进改进?
4.
产品关键指标的统计数据, 有什么规律? 为什么会这样? 从中可以发现什么线索, 对产品下一步策略有什么支撑性依据?
产品运维的三个层面
1. 管理与操作层面: 产品资源与属性的信息展示与查询; 提供哪些操作恢复产品的正常使用;
2. 监控与预警层面: 产品运行的实时状况, 透明度/健康度 评估, 预警;
3. 统计与决策侧面: 通过对产品关键指标的统计, 发现规律, 更好地规划后续策略;
产品运维的具体工作
(1) 产品新特性的运维新需求。 产品新特性上线之后, 必定要对该新特性进行可用性运维, 同时要考虑与现有特性的兼容与联接。比如云磁盘上线后,对云磁盘的管理不再依附于云服务器, 需要新开一个云磁盘的管理界面,一个快照管理的管理界面, 原有的磁盘快照管理也需要进行改造, 以适应本地磁盘与云磁盘的兼容和混用。
(2) 适应项目变更,保证运维系统服务可用性。拥抱变化, 应对变化, 在产品发展过程中, 常常会进行多个项目来进行产品的改进, 这种情况下, 不会有大的关键的新特性上线, 但是会产生内部结构变更, 比如数据库变更、依赖的外部系统服务的变更、线上环境变更等。 运维开发工作必须保持对这些变更的紧密关注, 紧密跟进, 才能保证不出差错。
(3)
产品全方位监控视图及
资源属性的关联管理。 一方面, 通过监控来提升产品运行状况的透明度, 使之逐渐可控; 另一方面, 需要逐步建立对产品健康度评估的标准, 能够对产品当前状态有一个基本的宏观评定。
(4) 用户体验与故障处理、工单效率提升。 运维系统的用户通常是技服、PE同学, 为他们提供有力的工具来诊断问题、解决问题, 从而更快地响应客户反馈, 对公司信誉有非常重要的间接影响力。 因此, 运维系统也需要进行仔细设计, 保证知识与操作的准确性、响应的流畅性、 操作流设计的适应性。
知识与操作的准确性, 是指技服\PE同学执行某个操作时,明确知道该操作做了什么事情,而且确实只做了这个事情,不多也不少; 响应的流畅性是指, 系统的响应必须稍快于人的操作速度和心理需求, 在该快速返回的时候不能阻塞, 在该缓的时候不要反应过敏, 导致用户误操作; 操作流设计的适应性是指, 操作流的设计必须非常便捷地切合问题的解决, 而不仅仅是提供了所需的功能, 但用户需要解决问题要多个地方跳转和切换, 影响效率。
(5) 从临时需求中挖掘问题和需求点。比如售后工程师不定时会提出一些临时需求, 这些需求往往需要快速便捷地响应, 而不能等待到发布。从重复性的临时需求中挖掘问题和需求点, 添加到运维系统的功能集中, 也是运维工作的一个重要方面。 比如, 售后工程师不时会需要获取批量云服务器的用户账号, 而当前系统中仅提供了查看单台服务器的账号信息。这可以形成一个需求点。
(6) 消除重复性的困扰。 有些功能设计不恰当会导致重复性的困扰。比如黑洞清洗操作中, 右侧显示的是该云服务器所在NC上的所有云服务器的攻击记录。 不止一次有同学反映右侧攻击记录的IP为什么跟左侧该云服务器的不一致, 会产生困惑是不是查错了。 实际上, 右侧这个显示实在应该放在 NC 视图中, 放在这里为了方便, 但给不知情者造成了困扰。
(7) 运维工作标准与检验的逐步建立。 更准, 更好, 更高效! 这永远是运维工作的格言和座右铭。需要逐步建立一套运维标准, 来检验当前运维工作的等级。 比如, 接到问题的响应时间(不一定解决,但一定要先响应, 类似异步接口), 定位原因的响应时间, 解决问题的响应时间; 故障时长; 是否检测出产品的重要缺陷; 运维工作流程;
故障处理记录与REVIEW
等;
(8) 琐碎事项的规范化处理。 经常会有一些琐碎的事情需要处理, 而且还很容易为此耗费时间。 比如, 开发需要订正数据库; 新入项目和团队需要申请各种权限等。 对于前者, 是否可以通过更好的技术来解决, 对于后者, 是否可以指派专人来进行申请, 申请人只需要提交申请哪些权限即可; 此外, 不同级别的开发/测试/技服/PE/业务支持 等角色各需要哪些权限, 是否可以有一些表格和标准可以参考, 而不是零碎地靠个人多次问询多次去完成。