在互联网公司，最明显的一个特点，那一定是加班。没有最猛，只有更猛，我们知道的有996、007、大小周，但我们不知道的还有很多。那互联网团队为什么总是加班呢？并且总是加班很晚呢？

大概原因有三点，业务迭代快、人力资源少、产品问题多。对于业务迭代快，这个没有办法，大家都是在敏捷开发、持续集成、持续交付；对于人力资源少，这个似乎也没有多少办法，现在都是在裁员、1人当1.5人用；对于产品问题多，这个有办法，只要做到这三点，别的不说，少加班是肯定的。

要保证产品问题少，其实也就等价于保障产品高稳定、高可用，总的来说就是这三点：完善的研发流程机制、较好的系统架构设计与实现、良好的个人质量意识。为什么是这三点呢？

我们来看看一个产品是怎么产生的，在需求确认之后，由研发进行技术选型、架构设计，然后进行开发、测试、上线、运维。这整个过程就是研发流程，核心抓手就是系统的架构设计和实现，核心影响因素就是开发者。

从研发流程机制来看，包含这几点：

1.在设计阶段，需要进行方案的技术评审；

2.在开发阶段，遵循团队内的分支模型，代码需要进行代码评审；

3.在提测阶段，要写单元测试并且运行通过；

4.在测试阶段，要进行全面的场景覆盖测试、接口测试；

5.在发布阶段，使用灰度发布或者蓝绿发布的方式逐步上线；

6.线上出现问题，立即回滚。

从系统的架构设计和实现来看，包含这几点：

1.技术选型，总的来说就是选用组件的功能满足度、可扩展性、性能、开发难度、社区活跃度这几个方面去进行考虑。底子特别重要，因为所有的业务都是在这上面运行起来的，一旦有问题，整个都玩完了，重构的成本也是特别大。正如万丈高楼平地起一样，选用的材料不好则崩塌是瞬间的事儿；

2.架构选型，总的来说就是SOA、微服务、无服务。SOA架构就是将单体式服务进行拆分，由不同的团队开发不同的服务，再通过ESB企业服务总线连接起来；微服务架构就是把业务的每个服务模块原子化，由不同的团队开发维护上线不同的服务，服务与服务之间通过MQ消息中间件或RPC远程调用连接起来；

3.系统设计，系统设计总的来说就是少依赖、不依赖、分布式、能降级。少依赖指的是各个模块之间尽量是拆分原子化的，因为一旦相互依赖，在开发、测试、上线、回滚这四个环节也是相互关联的，牵一发而动全身，这也是为什么我们拒绝单点应用，因为里面全都是各种依赖。我们希望少依赖，最乐观的情况就是完全不依赖，这时候在研发流程的每个环节都是独立的，各自迭代就好。分布式指的是将把服务分散在多个地方，在分担用户请求压力的同时，也相当于是做个保底，不至于一个服务挂了就全完了。能降级指的是在业务出现问题时，能有弱一些的解决方案，不至于让用户完全不能使用产品。

从良好的个人质量意识来看，包含这几点：

1.积极思考需求价值，需求最终是交付给用户的，研发人员也是用户之一，因此在实现需求时，除了可行性之外，也要更多的思考价值，避免做了很多无用功能，最后又砍掉。；

2.技术设计时思考可扩展性。业务是持续迭代的，除了产品经理要考虑未来功能的演进，研发人员在设计接口字段时也要设计的很灵活，用以支撑未来业务的扩展，不至于到新功能开发时，还需要推翻从来；

3.进行充分的自测和单元测试。测试人员一般进行的是黑盒测试，只有研发人员对代码是最熟悉的，最清楚代码逻辑的，因此通过充分的自测、单元测试能提高产品质量。

4.对一切抱有敬畏之心。保障产品的稳定性是开发人员最基本的素质，不以业务繁忙、个人情绪为理由而忽视对产品质量的保障，这点其实是最难的，因为我们往往都会受各种外界因素影响，以及技术真的发展演进太快了、有时候会出现计划赶不上变化。

总的来说，要保证产品高可用、低风险，只要做到了完善的研发流程机制、较好的系统架构设计与实现、良好的个人质量意识这三点，那就是妥妥没问题的。听说咱互联网人月收入五万，那也能有机会过的像五万，而不是每天都996、007，埋在电脑前码代码、修Bug啦～