咖啡男孩之SRE之路

混沌工程是推动监控体系完善的动力和方向，换句话说凡是混沌需要关注的指标就是有意义的指标，所以为了解决上述问题我们必须把这些指标数字化并纳入监控体系。对于用户行为此类复杂的指标设计在DataOps体系中不难找到标准答案，但对于混沌工程来说痛苦的点在于如何确定这些指标的结果是正确的？...

前言： 影响混沌工程进入生产环境的两大阻碍，我们前篇已经详细分析了第一个阻碍“最小爆炸半径”，本篇我们详细分析下第二个阻碍“故障工具的安全问题”。故障工具： 混沌工程的核心之一是故障演练，而模拟故障的组件就是所谓的故障工具。目前国内最好的故障工具应该是阿里开源的ChaosBlade，它可以覆盖到系统和网络层面大部分的演练场景，而且对容器云也有很好的支持。更详细的ChaosBlade的介绍请参考这里https://github.com/chaosblade-io/chaosblade/...

自混沌工程理念提出来之后，追随者甚多，实践者甚少，这是为什么？因为混沌工程是把双刃剑，稍不留神就会弊大于利，所以大家对混沌工程，特别是生产环境的混沌工程是慎之又慎。本篇将围绕最小爆炸半径提出3个问题，并给出自己的一些解法。混沌工程可直接在生产环境进行么？ 混沌工程的五大原则中有一条“在生产环境中进行试验”，混沌工程五级成熟度也把混沌实验的环境（预发布、灰度、生产）作为了评判标准之一，所以这个慢慢趋于生产的递进过程也就成为了行业大部分混沌工程推广的潜规则了。 其实这里面我个人觉得我们...

前言 2019年开始接触混沌工程，2020年开始我们的运维体系开始引入混沌工程相关的设计，2022年准备正式在生产环境落地。期间走过不少弯路，基本是摸着石头过河，该犯的错误犯过之后我们对自己混沌工程的前景充满信心！本篇博文想着重介绍下，混沌工程大家都或多或少有所了解，火了也有几年的时间，为什么能落地生产的还是寥寥无几，混沌工程的推广为何如此困难呢？五大原则 混沌工程的提出者给出了五大原则，很好的给我们指明了目标和方向，在项目中一切设计的准绳都必须围绕这五大原则，一旦偏离其中一个原则就...

在云中生下来就具备的能力就叫云原生。

1 成本 这里的成本分为对内和对外两部分。对外，也就是企业总共需要支付给云厂商的费用；对内，是企业内部费用分摊的问题。对外肯定是越便宜越好，这个也包括3个方面。1、公有云的报价 2、商务合作与折扣 3、合理的使用方式。这里重点解释下使用方式，以云实例为例，如果厂商A只有包月、按量两种收费模式，厂商B有包月、按量、预留实例券、竞价四种模式，在单价相差不大的前提下要优先选后者，因为在某些场景下可以利用预留实例券和竞价为我们节省大量的经费。2 稳定性 稳定大于天，这个是对公有云最重要的要...

BPF本质上是一种操控内核的开发技术，所以要彻底明白BPF就要先了解内核的相关知识。Linux两大运行空间 CPU将指令分为特权指令和非特权指令，对于那些危险的指令，只允许操作系统及其相关模块使用。操作系统的核心是内核(kernel)，可以访问受保护的内存空间和硬件设备，也就是能执行这些特权指令，而用户进程不能直接操作内核，只能执行非特权指令。 出于内核安全方面的考虑，操作系统将虚拟地址空间划分为两部分，一部分为内核空间，另一部分为用户空间。通过区分内核空间和用户空间的设计，...

需求：当后端服务能力不足时我们希望尽可能为更多优质用户请求提供服务相应，放弃部分劣质请求，待峰值回落或后端扩容后再无差别对待。前提条件：监控（观察）必须要有完备的监控体系能及时发现流量的波动，并能推算出后端剩余的服务能力。网关（控制）必须要有统一的流量入口用于访问统计和访问控制。模块划分：各个模块的作用：网关：流量入口，统计request，控制response。由于网关是高并发、低延时的应用场景，所以对于流量限制部分的判断一定要低运算、短链路，所以限制条件等已经要在网.

随着云计算思潮根深蒂固，越来越多的企业已经上云，其中公有云因易用、持续迭代、稳定等优势占据了云市场的大头。那么有个问题随之而来-你们是如何与公有云厂商进行对账的？虽然公有云的账单系统都已经做的非常完备，但对公有云的账单绝对不是下馆子看菜谱点菜付钱那么简单，小企业靠人力还是有可能对的清，大企业上千万的账单会直接把人劝退。我个人觉得目前还没有出现一款计费平台的原因有两点。原因一是基于我们对云厂商的信任（支付宝、微信支付都是阿里腾讯的，我们还信不过他们的云平台计费系统？），原因二是自建个对账系统是个超级复杂的

亚太内容分发大会暨CDN峰会一直致力于推动CDN产业深度融合发展和市场普及，现已成为亚太地区影响力最大的内容分发网络盛会。十年来，在以阿里云、网宿科技、腾讯云等亚太CDN产业联盟成员孜孜不辍的努力下，CDN产业已经成为基础性设施网络，以坚定的基石之姿，支撑起中国成为世界最大的互联网市场。随着全球数字化、“一带一路”战略的推进，亚太内容分大会暨CDN峰会的影响力正在逐渐向全球延伸，同时也将中国智造CDN及产业链推广向全球每一个角落。在6月10日上午举办的【内容出海论坛】上，芒果TV运维研发负责人

Spinnaker采用了微服务体系，而对于整套微服务体系的搭建官方是推荐采用halyard来搭建的。Halyard对于spinnaker的黑盒使用者比较友好，把对spinnaker的安装、部署、配置、管理等都封装成命令（其实命令也是够复杂的），但对于具有研发基础或者说对于spinnaker比较了解的人来说这种方式有点本末倒置了，本篇在原理上介绍下如何绕过halyard自己搭建spinnaker的微服务。从原理上来讲spinnaker分为“软件包启动”和“源码启动”，从运行环境来讲spinnaker部

在云原生领域不知不觉干了3年，又到了需要总结和重新规划的时候了。知识梳理首先给自己做了画像：绿色部分是自己在这个领域一直从事的工作，掌握的比较扎实的部分，其中加粗的部分自认为是专家了。蓝色部分是一直接触但还没机会开发相关产品的部分，对这些模块有一定了解但并不精通。红色部分是盲区，只是略懂皮毛。我觉得云原生领域可以有盲点但不能有盲维，后续要加强存储和安全方面相关的学习。AIOps or DevSecOps？Devops下一步有两个分支：AIOps和DevSecOps，虽然我有.

这是个真实的事故：2021/02/22 节后第一个星期一中午的准午餐时间，节后综合症导致的吊儿郎当的神经还未绷紧，突然办公室内全面报警，很多服务都出现或多或少的异常，大家不约而同地说“我去，我的服务里阿里云的机器没有了”！！。我的直觉告诉我这种批量操作不可能是误删，应该是程序或脚本引起的，赶紧联系阿里云审计日志中查下操作账号和源IP。结果是spinnaker账号在公司内网发起的请求。因为spinnaker的版本最近没有变动过，所以我第一反应没有怀疑spinnaker而是怀疑鉴权泄露了，立马修改了AP

前言： 行业里对码农的描述有很多种抬头：研发、开发、工程师等，我个人觉得描述最准确的应该是“工程师”，因为软件产品的开发本来就是个工程学的问题，只不过软件工程和土木工程的施工过程是正好相反的。土木工程是自下而上，先把地基搞好再一层层往上建设；软件开发是自上而下，先搭建空中楼阁，下面是怎么实现的并不重要。新概念： 我们都接触过很多编程思路的名词，面向对象、面向过程、面向服务等，其实做为一个软件工程师最应该具备的是“面向能力编程”。面向能力编程是软件架构和开发时的一种方法论，只关注自己需要实现的..

目录实现思路需要扩展的类型核心代码KubernetesApiGroupKubernetesKindKubernetesKindPropertiesKubernetesHandler效果图：deploypatch更复杂的类型Spinnaker的clouddriver对kubernetes支持本质是将UI入参转化到代码最终转换成本地kuber命令来实现的，因为其是通过“白名单”的策略来实现的，所以对k8s的支持比较有限，不在白名单内的资源类型是无法被spinna.

现在是2020年最后一个小时，由于工作原因我已经很静没有陪伴家人一起庆祝过新年了。现在的我一边盯着监控大盘，一边听着时间的朋友，一边用键盘把今年零零碎碎发生的事情总结成博文。其实精彩的人生不正是如此么？做好当前该做的事、了解别人在做的事和社会发展的总趋势、力所能及的帮助别人变成后来者的肩旁。做好该做的事世界不缺梦想家，缺的是实干家。同样一件事，抛开技术实力上的差距不说，为什么有的人能干好，有的人干不好，核心区别在于100分定义在哪里。比如开发一个产品，有些人的100分是能用就行，有些人的100分是稳

最近在对公司的Jenkins进行优化，发现每个运维人员针对自己的项目都写了一个自己的脚本，70%都是拷贝复制的，剩下的30%风格迥异。我现在也正在负责对整个CI/CD的过程进行进行优化，目前这种状况下如果添加或缩减一个关键，需要把所有的脚本都改一遍，这次的人力成本真的有点高啊。既然要动刀子，那就一步到位，引入点黑科技为以后铺好路，希望以后做CI/CD环节优化时不要再这么痛苦。如何提高Jen...

ELK，ElasticSearch+Logstash+Kibana三个组件的缩写，应用场景比较广泛：1， 用于微服务架构中日志收集、分析、展示功能的基础组件。2， 用于网站操作动作捕获监控、分析、展示功能的基础组件。ElasticSearch：承担存储和分析功能，原理和具体操作前面已经花了大量篇幅来介绍。Logstash：ELK架构的内容来源，负责收集和简单数据处理。Kibana：提供友好展示、报表统计功能

为了解决线程安全的问题，我们有3个思路：第一每个线程独享自己的操作对象，也就是多例，多例势必会带来堆内存占用、频繁GC、对象初始化性能开销等待等一些列问题。第二单例模式枷锁，典型的案例是HashTable和HashMap，对读取和变更的操作用synchronized限制起来，保证同一时间只有一个线程可以操作该对象。虽然解决了内存、回收、构造、初始化等问题，但是势必会因为锁竞争带来高并发下性能的下降。第三个思路就是今天重点推出的ThreadLocal。单例模式下通过某种机制维护成员变量不同线程的版本。