配置信息的版本管理
- 环境配置项（如配置中心地址）
- 应用配置项（如Jvm配置，路径配置，账号密码）
- 业务配置项（配置与业务行为相关，如功能开关）
软件工程
瀑布软件开发：重计划、重流程、重文档
敏捷软件开发：强调发挥人的主观能动性，提倡面对面沟通，拥抱变化，通过迭代和增量开发尽早交付有价值的软件。
敏捷宣言：
- 个体和互动高于流程和工具
- 工作的软件高于详尽的文档
- 客户合作高于合同谈判
- 响应变化高于遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
敏捷软件开发应遵循的12原则
- 尽早的持续交付有价值的软件，以便让客户满意，这是优先级最高的事情。
- 即使在开发阶段后期，也欢迎需求变化。为了让客户获得业务竞争优势，利用敏捷过程来应对变化
- 频繁交付可工作的软件，建议采用较短的交付周期（通常几周或一两个月）
- 在整个项目过程中，业务人员和开发人员每天能够一起工作一段时间
- 围绕积极的个体，建立项目团队。给他们需要的环境和支持，并相信他们能够完成工作
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强
- 以简洁为本，它是极力减少不必要工作量的艺术
- 最好的架构、需求和设计出自自组织团队
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现
持续交付4个核心原则
- 坚持少做
- 持续分解问题
- 坚持快速反馈
- 持续改进并衡量
常见架构模式
- 微核架构（核心框架+插件）
- 微服务架构（
- 巨石架构/巨石应用
巨石应用的优缺点 优点：
- 利于开发和调试
- 部署操作简单
- 易扩展（负载均衡+多server） 劣势：
- 对整体程序不熟悉的人来说，容易产生混乱的代码，污染整个应用，给老代码的学习和理解带来困难
- 难与新技术共同使用
- 只能将整个应用作为一个整体进行扩展
- 持续部署困难。为了更新一个组件，必须重新部署整个应用程序
架构改造实施模式
- 拆迁者模式（代码重构）
- 绞杀者模式（保持原遗留系统不变，当开发新功能时，重新开发一个服务，实现新功能，通过不断构建新的服务，逐步使旧系统失效，并最终替代它）
- 修缮者模式（将遗留系统的部分功能与其余部分隔离，以新的架构进行单独的改善，在改善的同时，需要保证与其他部分仍能协同工作）
低风险发布
- 蓝绿部署（AB两套环境，交替成为生产环境和测试环境）
- 滚动部署（从服务集群中选择一个或者多个服务单元，停止服务后执行版本更新，再重新投入使用，循环往复，直至集群中所有服务实例都更新到新版本，与蓝绿部署相比更加节省资源）
- 金丝雀发布（灰度发布）（泛指通过让一小部分用户先行使用新版本，以便提前发现软件的问题，没问题的话逐步扩大推送范围）
- 暗部署（指功能或特性发布前，将其第一个版本部署到生产环境，以便向最终用户提供该功能之前，团队可以对其进行测试并发现可能的错误。主要是用户无感知）
影响发布频率的因素
- 增量发布带来的收益和可能性
- 每次发布或部署的操作执行成本有多高
- 出现问题的概率与由这些问题带来的成本有多少
- 维护同一软件的不同版本带来的成本
- 高频发布对工程师的技能要求
- 支撑这种高频发布所需要的基础工具设施与流程完整性
- 组织对这种高频发布的态度与文化取向
数据监测
生产环境监测范围
- 资源监控（系统基础设施健康度）
- cpu、内存、Disk、Network
- 应用监控（应用程序运行健康度）
- 进程存活状态
- 是否正常对外服务，是否功能缺陷，是否正常连接数据库
- 是否有超时
- 应用服务抛出的异常和报错
- 业务监控（业务指标健康度）
- 如，用户访问量
- 页面浏览数
- 订单量、转化率、交易额等
数据的标准化，在功能实现方案之外，事先对业务数据的进行定义和规划
- 对业务指标的定义。即与该功能相关的业务指标是什么，与其他业务指标有哪些关联性，以及如何计算这个业务指标
- 数据事件的定义。即为了得到这个业务指标的数据，应该在产品代码的那个位置埋设监听事件，输入和输出格式是什么样的，与其他时间之间的关系是什么。
ps：缺乏经验的产品经理对功能的实现的关注度远远高于对数据的关注度
检测数据的3个衡量维度
- 正确性。
- 全面性。收集的信息是否足以支持团队做出决策
- 及时性。数据的发生到能够支持决策所需的处理时间足够短
告警海洋与智能化管理
每当出现生产事故后，事故复盘分析必须有两个行动项：一是数理当前日志检测和告警点，把相关人员全部配置一遍，生怕漏掉任何一个人；二是加入更多的监测点和报警。一方面是告警数量多，希望减少告警； 另一方面是害怕出事了没有告警，只能加入更多的告警。最终的胜利者通常都是后者。
事实上，很大一部分告警都会被接受者直接忽略，看都不看，原因主要有两点
- 告警信息的第一处理人不是自己
- 告警信息是一个预备报警
告警的原则
- 正确性及真实性
- 及时性
- 可操作性【当收到告警信息后，接警人应该可以针对这个告警做出相应的操作，否则告警信息就如同垃圾短信一样，应该将其屏蔽，因为它会令工作效率降低】
缓解告警海洋
- 通过关联分析，让监控点离问题发生地更近
- 通过动态阈值设定合理的告警
- 定期梳理告警设置，清理不必要的告警
- 通过人工智能动态解除告警
生产环境中的测试
- 创建自用的测试数据，确保不污染真实用户的数据
- 使用的测试数据尽可能真实
- 不要修改真实用户的数据
- 创建测试专用的用户访问凭证，登录生产环境