本篇文章是跟浙江移动信息技术部总经理，中国移动首席专家的王晓征总交流探讨后形成。首先，再复述下本文标题，Observabilty对运维没用，如果硬要说的精确点，exactly，对绝大多数的运维没用。为啥呢？Observability的三个环节是什么？Detect发现—Trouble

自打去年以来，可观测性Observability这个概念又非常的火，按照我的感受，在运维领域，这个概念是近两年即AIOps之后，热度最高的一个了。无论是国内还是海外的运维相关的公司，都给了自己一个新的定位，就是可观测性平台，或者叫做可观测云，相对应的产品也是层出不穷。对于我来讲，我看一个趋势，往往会从落地的角度，从实际情况来分析，反向去看，而不是单纯地看技术多么酷炫。所以，我观测了很久Observability之后，打算还是从实际情况入手来聊聊这个概念，看看可观测这个东西到底包含哪些内容？它们之间是什么关系？如果要落地，里面真正核心的、决定成败的又到底是哪些东西？先做个简要概述：Observability是来自控制论的一个概念：In

如果云厂商不想被IaaS的上限解读为全云天花板，那在PaaS云上必须有产品创新。云厂商在计算存储网络多个领域都有尝试，我建议大家以对象存储和CDN为正面例子，做好产品价值的实质性分析。

Slootman加入之后。团队的主营业务聚焦于ITSM（IT服务管理），也就是将IT运维过程中高频问题的自动化、常规问题的自助化、并发问题的有序化解决，并能实时跟踪和可视化问题解决的路径和流程。

总之，工业软件本质就是将力学、数学等各种学科的公式，通过算法的形式写进代码里面，如果目前学术界没有特定的公式，那么就需要开发人员自己去推导公式。有时候想想，开发工业工业软件的人，真特么必须是天才。

FlowSpec使得协议栈越来越复杂。互联网上各种魔改的开源BGP(FRR-OpenBGP/GoBGP)使得协议互通时出现Bug的几率急剧上升。当然最严重的问题是：BGP状态机和TCP的耦合：

开了个星球（当前免费），专门聊聊SRE，云计算、运维这些事，星球里互动性更强一些，有很多想法和内容，我会随时写到里面，慢慢会沉淀很多内容，当然如果内容积累足够多了，就要提高进入星球的门槛了。

主备、冷备、热备、双活、多活、同城、异地、多云，等等等等，这些保证业务高可用和容灾名词，我们经常会听到，不绝于耳。但是，真的当我们自己要去建设，选择方案时，就发现不知道该怎么选择和搭配了。结合近期我们的一些讨论，准备用几篇文章简单分享下我们的理解，今天先聊冷备。冷备是不是个好方案？这里的冷备我们可以理解为，是主站系统核心链路的镜像站点，应用、各类分布式服务以及底层基础设施都是独立，且启动的。它跟主站唯一的差别就是，正常情况下，不承载任何线上流量。理论上，只要有状态的数据（也就是各类分布式服务，如数据库、缓存、消息等组件）同步好，接入层流量能够灵活调度，当出现问题的时候，切入口流量，就可以顺畅的切过去。看上去很美好，但是实际操作起来，基本不可行。这里有一个关键点，就是业务应用，应用的代码和配置是随时在变化的。原则上，我们可以通过持续交付和运维自动化等等手段，确保每次变更都能够同步到备站点，并通过流程约束不允许有外部操作。所以，手段上，我们可以做到非常完备，流程上，我们可以设计的非常严密。但是，我们始终绕不开的一个命题，只要不承载真实的线上业务流量，我们就无法证明这个系统是可用的。何况，有可能是好几个月我们都不会发生真实的切换动作，所以，一个几个月没有经过线上流量检验的系统，在真正需要切换时，不会有任何人敢决策直接切换的。当然，以上是我们的直接推断，确实行不通。但是我们仍然要经过一些详细的论证，从其它角度看是否有解。从另外一个角度的论证过程当时我们讨论在冷备的前提下，应该怎么保证系统的可用性，没想到，论证的过程，反而进一步证实了冷备只是一个美好的愿望。1、通过模拟压测的方式。但是我们知道，压测的模型是根据线上业务模型来定制的，但是业务场景和逻辑每天都在发生变化，压测模型的同步有时是跟不上业务模型变化的。况且这个日常工作量要靠人，无法做到自动生成，所以基本不可持续。再就是，压测的结果检验是通过技术指标衡量，而非业务指标，也就是是否200ok，或者出现5xx之类的错误。业务逻辑上是否正确，并没有办法确保。这种情况就极易造成数据污染。数据故障的影响范围远远超过服务不可用的影响。所以，压测可以最大程度评估系统容量，但是无法保证系统业务正确性。2、切换后，接入线上流量前，QA介入验证。理由同上，工作量大，也无法覆盖到所有场景，时间不可控，完全起不到冷备节点的快速承载业务效果。3、定期模拟演练，确保系统周期范围内可用但是这里就有一个前提，冷备站点的建设目标，并不是全量建设，而是在极端状况下，确保核心业务临时可用，当主站点恢复后，仍然要切回去。这里暗含的一个意思就是，一旦需要做这个动作，业务必然有损，而且涉及范围非常大，这就意味着，每一次演练都要付出极大的业务代价。从这个角度，产品运营及决策者们是不会允许你经常干这种事情的。到这里，你会发现，连日常演练的条件都不具备了。4、一个绕不开的限制条件数据同步必然是单向的，为了保证数据一致，通常要确保备用站点是禁写的，以防止各类误操作引起的数据污染。所以，即使上面几个方案可行，基础条件上又不满足，因为根本无法写入数据，关键的业务逻辑根本不具备验证条件。最后，结论冷备只能是冷备，关键时刻并不能起到快速承载业务的效果，在业务容灾建设时，这个思路其实是不可行的。但是对于部分组件，比如数据库、大数据、文件，这些存储类的部件，做冷备是有重大意义的。也就是，后面我们在提到冷备时，应该叫做数据冷备、文件冷备、源代码冷备才有意义，或许会更准确些。如果感觉文章还不错，欢迎关注，持续贡献^__^

现在很多startup公司，直接在云上使用docker部署模式，对于基础设施就更不用投入太多精力去维护，所以这些公司都会讲我们的研发团队比较单一，只有开发，没有运维和测试，所有的事情开发都可以搞定。

AI时代，AIOps热炒，这篇算是蹭个热点：）。回到本行，我们运维应该关心的是什么：1、AIOps到底是什么？2、AI和Ops究竟是什么关系？3、AIOps到底会带来哪些改变（颠覆or提升）？按照Gartner的定义，AIOps是Algorithmic

这里面Docker发挥了一个很大的作用，就是提供了干净的，互不干扰的编译环境，且对于并发打包的情况，Docker快速创建多个并行的实例出来提供编译环境，使用完销毁，这个效率上的优势也是非常大的。

2、这些硬件的属性确定下来，比如服务器就会有SN序列号、IP地址、厂商、硬件配置（如CPU、内存、硬盘、网卡、PCIE、BIOS）、维保信息等等；网络设备如交换机也会有厂商、型号、带宽等等；

注：因为评论功能尚未开通，所以欢迎大家公众号留言讨论，因为后面还会有个番外篇，专门有一部分用来回答问题，如果大家有什么疑问可以公众号留言，我会选择一些典型的问题和答复放在文章中，感谢大家支持！

依靠团队的力量：单个人搞不定的事情，就发挥团队的力量，单个团队搞不定的事情，就跨团队协调资源搞定。所以，SRE岗位的要求很高，但是我们可以靠团队中具备不同能力的人协作，共同达成SRE的职责和目标。

1.基础部分：管理上标准化的落地，技术上CMDB、资源管理、应用配置管理以及应用上下线等日常基础工作自动化的建设。关于这一块内容，大家可以看一下我在2015北京ArchSummit峰会上的分享内容。

(2).稳定（质量）可以通过监控、全链路、强弱依赖、限流降级、容量评估、预案平台等措施，让业务运行更加稳定。做好这一点，需要有相对比较独立、专业的监控和稳定性平台来支持。