如果采用了微服务架构，应用将由多个服务组成，那么还需要考虑服务管理。以上全部考虑到之后，将其转化为系统设计，最后进行开发调试以及单元测试，完成了这些之后才可以将应用交给测试环节。
虽然这种理论存在争议，但对于工程师们来说，按照实践、学习和培训的方式进行重要性排序，大致是不错的。所以重视实践，在实践中成长是最重要的学习原则。
，比如在开发设计时会做三副本的高可靠保证，但是在运维侧则可能会认为副本所在的机器没有提供服务因此被错误下线掉。
所以，DevOps 实际上包含了两层含义，首先是将开发、测试、运维变成一个团队；其次，还需要让整个团队的心智统一，这也是DevOps 真正的挑战。
挑战一：亟需完善的生命周期管理与服务治理方案
在一个频繁迭代的系统中，每个应用会经常性面临新版本发布需求，需要对应用的上线、下线、更新、回滚等流程进行集中性的管理，并配合精细粒度的灰度发布手段，减少版本迭代对业务造成的影响。
自动化应用交付流水线
回顾一下当有了这些能力之后，如何实现自动化应用交付流水线。在源码阶段，可以实现代码质量静态检查，保证 CheckIn 的代码质量。当 CheckIn 到代码库之后，会自动运行单元测试，并且产出交付物。
- 向上
Session 提供了业务可切入的接口，用户只需实现 EventListener 就可以将 Getty 接入到自己的业务逻辑中。
目前 Session 接口的实现只有 session 结构体，Session 作为接口仅仅是提供了对外可见性以及遵循面向编程接口的机制，之后我们谈到Session，其实都是在讲 session 结构体。
通过 API 优先的设计模式，我们对独立的服务进行稳定性架构设计、容量规划；我们还可以对独立的 API 进行故障注入、稳定性演练，来消除系统性的稳定性风险。
但是换环境要有度，不能不断的调换，否则自己就很容易进入一个疲乏状态，以前的积累也会逐步清零。
2、换不了环境才积极。网络上甚嚣尘上的 35 岁焦虑论，让很多人不敢辞职，不敢换环境，所以只能“积极工作”。
他们对产品进行了大改版，并在较短时间内实现了用户数量快速增长，这是一个很好的数据驱动案例。反观国内，大一点的创业公司会优先考虑如何做概念，如何存活下来，像上述那样用数据实现业务驱动的很少。
再往下就是产品板块，包括产品版本、功能模块以及跟其他产品的协同。
向上要跟公司目标对齐，横向要跟合作团队对齐，向下是具体的产品功能拆解。需要注意的是：定好目标，目标不要多，最好只有一个或者两个。
