SRE团队通常有一套对项目的部署和维护的标准，在接手一个项目的维护工作之前，会用这个标准对项目进行评审，看是否适合由SRE来接手，项目是否需要做一些整改。一旦解决接手维护工作，就会组织对SRE进行项目的相关培训，做好充分的接手准备。这样，有利于SRE能够在接手项目维护时，就对项目有较好程度的了解，利于后期的故障应对解决。





这样一套标准和培训流程，挺有借鉴意义的。在服务的部署/维护上实现了一定程度的标准化，可以减少一些繁杂的运维工作量，便于各个项目的运维管理。同时，对SRE团队进行必要的项目知识培训，包括系统架构、调用链等。这样，在突发事件出现时，运维人员能够更多的承担定位解决工作，而不是出现问题第一时间是找研发人员寻求帮助，减少时间和沟通成本，让故障更快的得到解决。也能在一定程度上减少研发的工作量，减少运维应对紧急故障的心理压力。对于一些故障/事故的处理，需要写事后总结。正确的事后总结，并不是对于某个人或某个团队的指责与批斗长文，而是要详细且对事不对人。一份优秀事后总结，不仅可以作为on-call工程师应对紧急问题的参考，还可以用于新加入的SRE的培训材料。

SRE的工作包括项目工作（我认为项目工作可以理解为包含所有需要较长时间来完成/调试的具有较大工作量的工作，比如写一个复杂的脚本、部署一套项目环境等）和中断性工作（如：on-call告警处理、临时日志/配置文件查看等临时性短暂性的琐碎工作）。在这两者之间需要寻求一个平衡点，保证项目工作和中断工作能够良性进行。这个平衡点因人而异，因此团队管理者应该研究怎样更好地分配团队成员的工作，以保证减少成员的工作中断，提升工作效率。如果要求一个SRE既要正常保障项目工作的正常进度，又要其在同时应对on-call、临时支持等中断性工作，可能会导致SRE的压力非常大，更容易对工作感觉到疲惫。因此，如果要求一个SRE在项目工作上能够取得进展，管理者可能就需要减少其中断性的应付工作，保障其工作不被打扰；如果这个时间段的中断性工作较多，那么可以安排一位SRE当天专职做中断性的应对工作。对于传统运维，亦是如此。

一名运维/SRE工程师的项目工作总是被中断性事务打扰，可能会带来这样的后果：1、增加误操作风险，尤其是涉及生产环境的操作；2、工程师的工作思维被突然打断，在完成了中断性事务之后，就需要花较长时间将思维恢复到之前的状态。中断性次数如果太多，这样上下切换的时间成本太高，不利于提升工作效率；3、如果一个工程师每天都面临在项目工作和各种中断性工作中相互切换，可能会让其觉得工作负载很高，工作压力大，这种状态是不能持久的。流状态就是一种极度的专注，专注到无我、忘我的状态，是一种入神的状态。当人在这种状态中工作，可以很好的提升生产力，也可以提升创造性，甚至艺术创造性。但是当被打扰时，人就会从这种状态中脱离出来，因此，作为一个管理者，需要想办法让自己团队的每一个人都能够尽量的处于这种流状态中工作并且不被打扰。

总之，本书介绍的很多理念、技术知识和Google内部的一些案例、工具平台，虽然不能完全照搬照抄，可是对于其他的公司，也具有一定的参考意义的。而从一名普通的运维工程师来说，读这本书：
1、可以了解书中提到的一些技术，扩大自己的知识面；
2、学习紧急事故的处理方法，了解SRE平常的工作内容、工作理念和方式；
3、学习如何做一名SRE工程师。和自身进行对比总结，如果要从一名传统的OPS工程师转型SRE，还欠缺什么？是理念、是平台、还是自身技术栈，应该怎样去提升自己。

那么对于一名团队管理者，本书也提出了很多有价值的参考：
1、SRE团队是什么，他们的工作内容和工作模式是什么样的？
2、你需要一个SRE团队还是一个传统的OPS团队？想要打造一个合格的SRE团队，你可以从哪些方面入手？
3、对于一个团队，合理分配工作的重要性，可以怎样去提升团队的能力与工作效率，同时能减少员工额外的工作负荷？
4、一个技术团队，可以从哪些方面去提升团队的技术能力与综合素质？我并非一名管理者，一些想法或许有不妥之处。但是我始终提倡：科学提升工作效率，防止过度负荷。一份好的工作，一个好的团队，不应该是让人长期的无休止透支，而应该是有松有紧、张弛有度，这样才能持久地稳定发展。毕竟人活着，生命里不该是只有工作，还应该有生活、有自我。

SRE团队通常有一套对项目的部署和维护的标准，在接手一个项目的维护工作之前，会用这个标准对项目进行评审，看是否适合由SRE来接手，项目是否需要做一些整改。一旦解决接手维护工作，就会组织对SRE进行项目的相关培训，做好充分的接手准备。这样，有利于SRE能够在接手项目维护时，就对项目有较好程度的了解，利于后期的故障应对解决。





这样一套标准和培训流程，挺有借鉴意义的。在服务的部署/维护上实现了一定程度的标准化，可以减少一些繁杂的运维工作量，便于各个项目的运维管理。同时，对SRE团队进行必要的项目知识培训，包括系统架构、调用链等。这样，在突发事件出现时，运维人员能够更多的承担定位解决工作，而不是出现问题第一时间是找研发人员寻求帮助，减少时间和沟通成本，让故障更快的得到解决。也能在一定程度上减少研发的工作量，减少运维应对紧急故障的心理压力。对于一些故障/事故的处理，需要写事后总结。正确的事后总结，并不是对于某个人或某个团队的指责与批斗长文，而是要详细且对事不对人。一份优秀事后总结，不仅可以作为on-call工程师应对紧急问题的参考，还可以用于新加入的SRE的培训材料。

SRE的工作包括项目工作（我认为项目工作可以理解为包含所有需要较长时间来完成/调试的具有较大工作量的工作，比如写一个复杂的脚本、部署一套项目环境等）和中断性工作（如：on-call告警处理、临时日志/配置文件查看等临时性短暂性的琐碎工作）。在这两者之间需要寻求一个平衡点，保证项目工作和中断工作能够良性进行。这个平衡点因人而异，因此团队管理者应该研究怎样更好地分配团队成员的工作，以保证减少成员的工作中断，提升工作效率。如果要求一个SRE既要正常保障项目工作的正常进度，又要其在同时应对on-call、临时支持等中断性工作，可能会导致SRE的压力非常大，更容易对工作感觉到疲惫。因此，如果要求一个SRE在项目工作上能够取得进展，管理者可能就需要减少其中断性的应付工作，保障其工作不被打扰；如果这个时间段的中断性工作较多，那么可以安排一位SRE当天专职做中断性的应对工作。对于传统运维，亦是如此。

一名运维/SRE工程师的项目工作总是被中断性事务打扰，可能会带来这样的后果：1、增加误操作风险，尤其是涉及生产环境的操作；2、工程师的工作思维被突然打断，在完成了中断性事务之后，就需要花较长时间将思维恢复到之前的状态。中断性次数如果太多，这样上下切换的时间成本太高，不利于提升工作效率；3、如果一个工程师每天都面临在项目工作和各种中断性工作中相互切换，可能会让其觉得工作负载很高，工作压力大，这种状态是不能持久的。流状态就是一种极度的专注，专注到无我、忘我的状态，是一种入神的状态。当人在这种状态中工作，可以很好的提升生产力，也可以提升创造性，甚至艺术创造性。但是当被打扰时，人就会从这种状态中脱离出来，因此，作为一个管理者，需要想办法让自己团队的每一个人都能够尽量的处于这种流状态中工作并且不被打扰。

总之，本书介绍的很多理念、技术知识和Google内部的一些案例、工具平台，虽然不能完全照搬照抄，可是对于其他的公司，也具有一定的参考意义的。而从一名普通的运维工程师来说，读这本书：
1、可以了解书中提到的一些技术，扩大自己的知识面；
2、学习紧急事故的处理方法，了解SRE平常的工作内容、工作理念和方式；
3、学习如何做一名SRE工程师。和自身进行对比总结，如果要从一名传统的OPS工程师转型SRE，还欠缺什么？是理念、是平台、还是自身技术栈，应该怎样去提升自己。

那么对于一名团队管理者，本书也提出了很多有价值的参考：
1、SRE团队是什么，他们的工作内容和工作模式是什么样的？
2、你需要一个SRE团队还是一个传统的OPS团队？想要打造一个合格的SRE团队，你可以从哪些方面入手？
3、对于一个团队，合理分配工作的重要性，可以怎样去提升团队的能力与工作效率，同时能减少员工额外的工作负荷？
4、一个技术团队，可以从哪些方面去提升团队的技术能力与综合素质？我并非一名管理者，一些想法或许有不妥之处。但是我始终提倡：科学提升工作效率，防止过度负荷。一份好的工作，一个好的团队，不应该是让人长期的无休止透支，而应该是有松有紧、张弛有度，这样才能持久地稳定发展。毕竟人活着，生命里不该是只有工作，还应该有生活、有自我。