我们做事都是有一个思想的，即便是没有主见的人，那也有思想，只不过是他人的思想
工作也应有思想
那么，我们的思想是什么？
- 要有从整体上了解业务的能力，一栋摩天大厦，不光要从内部看，还要从外部看，这个从外部看的能力，就是整体的能力，有了这个能力，我可以看到一步一步缩小，像显微镜放大一样，不断追踪到具体服务，进程，甚至代码
- 贯穿全程的能力，当然可以理解为全链路，全调用链，一个请求，从头到尾，经过的环节，我都要有办法看到
- 服务无状态化，将环境看成是平的，杜绝服务必须跟着机器走的情况，所有环境应该是统一的，服务理论上应该可部署到任何环境下，不论是物理机还是容器吗，至于监控指标，日志收集等，同样都是服务
- 在SRE的眼中，一切软件都是服务，一切硬件都是资源，怎样保证资源合理，就这涉及到资源分配，服务治理。
- SRE的工作理念，保障可用性，保证成本，提高效率，SRE脱胎于运维，但是要摒弃传统运维思想，举个例子：当不存在发布系统的时候，为保障可用性，我要控制发布环节。而为了提高效率，我做了发布系统，从整体上对发布进行强约束，保证了可用性，这时候应该是研发自己部署，提高发布效率
- 任何处于调用链中的服务，都具有两个角色，被调用方和调用方。作为被调用方，应该有完整的监控指标和足够多的日志信息量，作为调用方，同样应该有完整的监控指标和足够多的日志信息量。作为被调用方，我们大多经过都是DNS->LVS->L7，L7是后端最为紧密的服务，在SRE的视角下，我们应该将业务相关，服务细节之外的指标都囊括进来，包括监控的打点，接口的多项指标，L7日志的收集处理分析等等，这些都是服务外围的东西，不应让研发过多的在上面浪费精力，使研发更聚焦于服务本身的设计与实现。而作为调用方，我们应该具有检测被调用方相关指标的能力，请求的域名，端口，服务，返回码，响应时间，QPS，实例，等一些可以触及的指标，当出现问题时，不至于抓瞎，并且可以向被调用方提供足够多的信息
- 自动化 >= 工具化 > 脚本化，不要总想着造轮子，现有工具的复用总比新起一摊子风险小得多
- 发布系统的重要性，任何服务势必都要走发布系统，且控制着发布的逻辑与频率，同时具有统一线上环境的作用，运行用户的指定，权限的设定，目录的规定，使安全问题和troubleshooting，日志收集等等都能获益，发布系统和监控系统相兼容，可以在部署时直接获取服务相关外围指标，不需研发手动处理
- 中间件的整合，例如各个语言用到的公共库或公共组件，都应纳入统一管理，杜绝像fastjson漏洞这种一出问题，万人手调的麻烦，同时也可保证有性能问题，安全问题组件的完美下线，没有漏网之鱼
- 压测工具自动化平台和安全测试平台，这个是大多数公司，大多数业务的短处之一，研发编写好代码，测试，上线，都没有经过严格的测试，即便有要求，现有大多数工具也是操作繁琐，更没有和基础设施整合，如果在审批通过后上线前的环节加入自动化压测工具和安全测试工具，可以及时发现性能瓶颈和安全问题，避免上线后回滚的尴尬
- 效率的提升，这个是方方面面的，永无止境的