IT运维笔记
凤凰项目：一个IT运维的传奇故事
这是一本很有节奏感的书，就像译者说的，“实在想一口气读下去”，毕竟小说总是比技术数据更有乐趣吧。
对于很多人来说，书里的故事，就是自己正在发生的，或者每个人都将遇到的，并告诉你如何解决、如何提速业务认可度的故事。
这本书的翻译整体还可以接受，虽说人名、术语或多或少有些小纰漏，偶尔有些生硬，但是不影响理解啦~
曲线的形状表明，当资源使用率超过 80% 时，等待时间就会直线上升，高资源使用率导致的破坏性是致命的。如果不进行处理，那任务队列永远不会完成。
最后：
期望各个职能环节（开发、QA、运维、业务部门等等），能自上而下的考虑问题，问题发生时，多方能互相理解并认识到：
“如果开发和IT运营都无法达成各自的目标，这无可避免地将导致灾难发生，最终大家都是内部战争的输家。”
对于很多人来说，书里的故事，就是自己正在发生的，或者每个人都将遇到的，并告诉你如何解决、如何提速业务认可度的故事。
三大工作法：
1，优化开发到运维工作流（按工作流执行） --------- 方法：持续构建/集成/部署、严控变更、看板 2，价值流快速、持续反馈（回馈） --------- 方法：自动化测试、敏捷 3，建立文化（学习、实践） --------- 方法：持续改进四种工作类型：
1，业务项目 2，IT内部项目（姑且认为是例行工作） 3，变更 4，计划外工作（事故、问题）资源忙碌百分比
这是我觉得书特别棒的一张图：等待时间 = （忙碌百分比）/（空闲百分比）
曲线的形状表明，当资源使用率超过 80% 时，等待时间就会直线上升，高资源使用率导致的破坏性是致命的。如果不进行处理，那任务队列永远不会完成。
最后：
期望各个职能环节（开发、QA、运维、业务部门等等），能自上而下的考虑问题，问题发生时，多方能互相理解并认识到：
“如果开发和IT运营都无法达成各自的目标，这无可避免地将导致灾难发生，最终大家都是内部战争的输家。”
对于很多人来说，书里的故事，就是自己正在发生的，或者每个人都将遇到的，并告诉你如何解决、如何提速业务认可度的故事。