《进化-运维技术变革与时间探索》

[superhj1987]

Apache Traffic Server置于Nginx反向代理和应用层之间，负责拼装静态信息和动态信息。

构建统一的配置管理平台，不允许密码信息出现在配置文件中，尤其不允许以明文形式出现。

在预发布环境和生产环境之间增加办公室环境-小蘑菇环境，劫持办公网流量来测试。

[superhj1987]

Java自动化构建流程：

1. 准备好JDK的编译镜像，此镜像环境和生产环境保持一致：OS版本、内核参数以及JDK版本等基础环境。启动一个构建任务时，就创建一个对应的Docker实例，做为独立的编译环境。
2. 构建任务根据应用配置管理的Git地址，将代码克隆下来放到指定的编译目录。Docker实例启动后，将编译目录挂载到Docker实例中。
3. 执行mvn package命令进行编译打包，生成可发布war的软件包。
4. 构建完成，将生成的软件包放到指定的构件库目录（可以用svn管理），或者直接发布到maven的构件库中，然后将实例销毁。

[superhj1987]

Java中的依赖规则限制：不允许依赖snapshot版本，不允许引入有严重漏洞的版本；限定某些软件包的最低版本发布。

将maven构建过程中生成的dependency:list文件将GroupID和ArtifactID做为关键字，与设定的版本限制规进行匹配。

[superhj1987]

故障定责的三个维度：

1. 变更执行：变更方没有及时通知到受影响方，事先没有进行充分的评估，责任在变更方；通知到位，受影响方没有做好准备措施导致出现问题，责任在受影响方；变更操作的实际影响大大超出预期，导致受影响方准备不足，责任在变更方。
2. 服务依赖：私自调用接口、调用方式不符合约定规则，责任在调用方；服务方没有明确示例或说明，导致调用方出现问题，则责任在服务方。
3. 第三方责任：机房IDC电力故障、服务器故障、网络故障，如果确实是不可抗力因素导致的，责任在第三方；自身冗余或故障预案问题，责任在应用Owner。

[superhj1987]

高压线规则：

1. 未经发布系统。私自变更线上代码和配置
2. 未经授权，私自在业务高峰期进行硬件和网络设备变更
3. 未经严格的方案准备和技术评审，直接进行线上高危设备操作：交换机、路由器、防火墙
4. 未经授权，私自在生产环境中进行调测性质的操作
5. 未经授权，私自变更生产环境数据信息

[superhj1987]

故障模拟：

1. IDC层面：人为破坏模拟
2. 系统层面：开源或者Linux系统自带工具支持：Stress工具模拟CPU升高，dd命令模拟磁盘IO，tc模拟网络问题
3. 应用层面：模拟RT升高、抛出异常、返回错误吗。用Spring的注解功能在运行时模拟异常状况，然后有针对性地看各种限流降级和开关预案策略能否生效。

可参考NetFlix的《Chaos Engineering》一书，NetFlix的Chaos Monkey。

[superhj1987]

运维问题的本质是架构不合理。因此运维是技术架构的管理者，从效率、成本、稳定性来检验架构是否合理。

[superhj1987]

技术运营的过程：

平台开发->推广落地->数据分析->问题总结->优化反馈 （圆形闭环）

[superhj1987]

安全规则平台：

• 代码审计
• 黑盒扫描
• WAF： Web Applicaiton FireWall
• 主机安全
• 堡垒机系统
• 入网管控
• 安全开发组件

[superhj1987]

此书基本涵盖了成熟互联网公司的运维技术体系。有不少东西都是当前公司没有做的，或者说不是合适的引入时机。书中阐述的运维思路（运维是技术架构的管理者）确实值得运维人员学习。