开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，（共2150人左右 1 + 2 + 3 + 4 +5） 新人奖直接分配到5群,另欢迎 OpenGauss 的技术人员加入。
最近临时工新开了一个系列，公司让我们每周选择一本书来读，并写出读后感，我为我自己的团队选择了此本书。这里并不是要学习技术，而是将一些DBA 的普世价值观，来进行灌输，现在不少的DBA 同学对于一些基本的DBA 职业的普世观都没有，可惜了。
读完这些内容我不知道你们总结出什么，我总结有以下几点
数据库的故障，一般发生在业务的高峰期，故障的严重性与系统的重要性是成对等的，平时不出问题不意味着没有问题，而出了问题后的情况下找到问题的核心原因，可能很简单，但解决起来很复杂。尤其是核心的业务，越是急于处理处理问题，长时间的工作会给人带来疲劳感，尤其是测试和生产两个环境对切。
此时，必须有确认的机制，如两人确认机制，测试和生产两台机器的工作机制，让已经麻木的大脑在处理事情的时候，减少出现不应该出现的简单性错误的可能性。
读完这些文字我不知道你有什么感想，我的感想就是DBA 就是一个网状思维的综合体，如果你只将问题定位限定于数据库，那么你的很多问题是无法进行处理的，你需要从数据库的知识在无法命中问题的时候，产生发散性的思考，并对怀疑的问题，反复进行验证，因为一次的验证可能范围不够，或验证没有到对应的时间或对应的状态。导致验证没有出现问题，所以还是要思维严谨，并一次性的排查问题。而不要排查和没有排查一样，然后在怀疑，在排查，反反复复，那么会失去客户的信任，让自己也无法面对后续的问题处理中对于一些资源的要求。
笔者老师也总结了一些处理故障中问题的经验。
最后的感悟，其中虽然未点名，但是中国式的问题处理和汇报的机制，让上层的人员无法获得真实的问题处理的结果，这点在很多甲乙双方的数据库服务中，经常会体现。
比如甲方的一些失误导致的问题，乙方需要进行隐瞒和包装，所以真正的故障所在，可能一线的人员要更清楚问题的产生和解决，但也有可能是一个点，总体的问题还的向上管理，如此次的问题，看似是数据库的问题，但实际是网络的问题，而这家企业的项目经理得到的故障是各种问题，在数据库的问题的处理中，也有很多情况是这样的比如，比如是程序设计的问题，SQL 写法有问题，导致的数据库问题，被推倒数据库层面，让数据库来解决的事情，层出不穷，而最终这样的问题解决不了，所以还需要数据库人员，除了数据库层面的知识，还要有更多其他的知识来辅助问题的解决，如开发的一些常识，架构的一些常识，硬件的一些常识等等，光掌握数据库的知识，不足以解决复杂性的问题。
