2 迭代

服务发布上线，往往并不是结束，而仅仅是长周期维护的一个开始。

我们通常对发布到线上的服务或产品，添加新的功能、优化用户体验的开发行为，称作迭代开发。

迭代开发一般有两个发起方：程序发起，产品发起。

程序发起迭代

程序发起的原因，主要有日志完善、bug修复、架构优化。

日志完善

服务发布后，需要一直关注其运行状态，这个工作主要通过观察日志来完成。

当线上服务出现一些比较难以定位的问题时，一般需要增加更详细的流程日志，在怀疑的地方添加输出，进一步确认问题。比如服务随运行时间变长内存不断增长（内存泄露）；某个用户被卡住，无法完成退出流程（卡人）；服务偶发或频繁中止运行，退出程序（宕机），没有dump或无法从dump中提取到有效信息；服务在某个环节卡住，不再运行，后续不再打印日志（死锁）等等。

当服务出现异常，已知的条件无法定位问题时，就需要增加日志，用于排查问题。

bug修复

发现线上服务运行异常，确认bug存在，需要对bug进行修复。

修复完成后，一般由开发发起迭代更新，灰度发布一个服务，观察是否解决问题。确认解决后，全网发布。

架构优化

项目开发有一个原则是，满足当前的业务需求。

公司进行项目开发，一般都是有时间要求的，需要在限定周期内完成业务支持。因此，在初期设计时，尽量考虑全面，但有些内容耗时较长，但对当前业务影响并不大的时候，可以先简化处理，先实现功能，后面再迭代优化。一句话概括就是：满足当下需求，不需要过度设计。

随着项目在线上运行，业务推广等因素，服务同时在线的人员会越来越多，先前符合需求的设计，需要改进和优化，才能适应最新的场景。

比如开始设计的聊天室服务，只有一台单点服务，可以支撑5000人同时在线。后面人数上升到1w，单台服务无法承载，需要增加服务器数量，多台服务之间需要保证聊天室ID唯一，不能冲突，这时候就需要程序发起迭代，进行架构优化。

产品发起迭代

最常见的迭代，还是由产品发起的迭代。

产品经理或策划，会关注产品的运行数据，分析竞品（竞争对手的产品）的功能，了解客户的需求（论坛、客服、粉丝反馈），确定产品的迭代方向。

功能迭代

经常会有增加功能的需求，很多功能产品也不确定效果如何，就先按照设想需求开发完成，上线后观察功能使用效果，然后进行功能调整，再关注调整后的效果，如果效果一直不理想，就需要删除相应功能。

天下文章一大抄，产品开发也是一样。当市场上有火爆产品的时候，模仿并进行微创新就是一个主流思路，也是成本最低，试错率低，效率高的一种方式。

当自身产品已经达到行业头部，市场占有率数一数二的时候，别人都在抄你，你就很难再找到抄的对象了。此时，不断的尝试、调整、验证就成了主要的迭代思路。

大公司体量大，用户多，盈利模式成熟，组织体系复杂，对现有产品进行大规模改动的动力不足。俗话说，船小好掉头，这也给小公司发展留出了一些空间和机会。

统计需求

产品需要关注线上产品的运行数据，这些数据都需要服务收集、分析并展示（有些统计需要客户端收集信息）。

以游戏服务为例，统计数据最关注的有用户活跃度，营收数据，用户游戏行为数据等。

用户活跃度包括每日用户上线人数，每日峰值在线人数，24小时按分钟在线人数曲线，用户平均在线时长，次日留存，七日留存等。

营收数据是指用户游戏过程中涉及的到金融变动，比如道具使用、表情发送、游戏输赢等。

用户行为数据包括用户的游戏动作，技能水平，操作偏好等。

产品策划人员根据统计结果，分析调研，确认下一次迭代目标是什么，是提升活跃度，还是提升付费率，或者提升付费的额度。确定好目标后，再针对性的提出策划需求。

一次迭代完成后，再关注统计数据变化，看是否达到预期，分析原因，继续进行下一次迭代。

而这些统计需求，也是在不断完善，新增一个统计点，就需要在相应的触发逻辑处增加埋点，以事件的形式将数据发送给后端服务，用于收集、统计、分析、展示。

因此，新增统计需求，也是发起迭代的一种驱动因素。