mujingluo的博客

这是许多运维人员长期陷入的一个误区，认为解决故障的能力是特别重要的，总是把更多的时间放在了如何提高个人技术和应急处理能力上，造成这个的原因是多面的，有运维人自身认识问题，也有KPI制度的不合理问题，老板对运维的认知问题(认为运维和研发是一样的，喜欢见到运维与研发一样忙碌)，还有历史留下的繁杂技术包袱问题。而故障告警的作用则是对一些不可知、不可抗力因素和无法自动化的问题的兜底，告警的出现就一定是需要人工立即介入的事件，而人工的介入一定是有时延的，等到人去解决的时候，往往是业务已经受到了影响。

在数据库领域中，高可用的方案一般是主从(主备)和分布式两种架构，主从架构的代表如MySQL，分布式架构的代表如TiDB，但Redis却是少有的两种架构都兼具的存在，主从架构的哨兵模式和分布式架构的集群模式，那么为什么已经有了哨兵模式的高可用架构，Redis还要有分布式架构的集群模式呢，我们来一一分析。

通过详细介绍RDB、AOF以及混合持久化这三种主流的持久化方法，我们不仅学习了它们各自的工作机制和配置策略，还探讨了它们的优缺点，然后根据自己的实际需求选出合适的持久化方式。RDB：适合数据备份和灾难恢复场景。AOF：适合对数据丢失有严格要求的应用。混合持久化：适合快速的数据恢复和高数据安全性的场景。

在新版本中，苹果的研发团队对数据混合策略进行了改进，这使得模型在多文本图像理解、视觉引用与定位以及多图像推理方面的能力得到了显著提升。苹果公司最近发布了一款具有里程碑意义的多模态AI大模型MM1.5，这款模型在前代MM1的基础上进行了显著的改进和升级。尽管MM1.5在多项基准测试中取得了优异的表现，但苹果团队仍然计划通过进一步融合文本、图像和用户交互数据，并设计更复杂的架构来提升模型对移动设备UI的理解能力，从而加强“苹果牌”AI的实力。

TCP（传输控制协议）和UDP（用户数据报协议）做为两种被广泛使用的协议，它们在处理数据时采用不同的机制，那么有一个问题，在同一系统内，TCP和UDP的服务是否可以使用同一个端口呢？首先我们先了解一下TCP/UDP和端口。

比较欠缺的是，目前后端的框架只支持fiber、chi、net/http，其余主流的gin、echo等目前尚不支持，但在已看到gin和echo在筹备中状态，可以持续关注。

互联网行业内对运维的需求一般遵循1:50的规律，即1个运维支持50人的技术团队，有些公司的比例可能更高，但总体上来说，运维团队的规模往往能够真实的反映出公司的规模和实力。

共和国的75周岁之际，重温了我心中的经典电视剧《人间正道是沧桑》和小说《远东朝鲜战争》，在看到剧中杨立青在东北战场被任命为“特别部部长”的情节，以及志愿军总后勤部的成立过程及洪学智将军后勤工作的历程时，突然有了同频共鸣——这不就是红色版的“SRE”嘛。

弹性伸缩是公有云和Kubernetes独有的特性，如何设计使用弹性伸缩是SRE工作的重点之一。

做为一个有点经历的SRE工程师，每当入职一家新的公司时，财务账单是必看的资料之一，而日常工作中，每周或者每月，也必然会抽出时间看一下账单报告，为方便获取想要的账单，还曾基于业务架构开发专门的账单生成程序。

如果你在升级到2.476或2.477版本后遇到Jenkins无法启动的问题，可能需要升级Tomcat到10版本，或者切换到Jenkins提供的servlet容器，因为Jenkins 2.475及以后的版本包括了对Spring框架、Spring Security和Java EE的升级。Jenkins 2.477版本在2024年9月17日发布，此版本中包含了一些增强功能和错误修复。此外，还有一些针对开发者的增强功能，比如添加了当计算机变为空闲时的新监听器。

合理配置Redis的过期策略和淘汰策略，可以有效管理内存，提高Redis的性能和稳定性。根据不同的应用场景和业务需求，选择合适的策略至关重要。

Kubernetes v1.31 版本的新特性为用户提供了更安全、更可靠、更高效的容器编排平台。通过这些特性的实现细节，用户可以更好地理解和应用这些新功能，以满足他们的业务需求。

CNI（容器网络接口）规范为容器运行时和网络插件之间提供了一个通用的接口，旨在实现容器网络配置的标准化。网络配置的格式：定义了管理员如何定义网络配置。请求协议：描述了容器运行时如何向网络插件发出网络配置或清理请求。插件执行过程：详细阐述了插件如何根据提供的配置执行网络设置或清理。插件委派：允许插件将特定功能委托给其他插件执行。结果返回：定义了插件执行完成后如何向运行时返回结果的数据格式。

近两年，AI确实迎来了大爆发，2023年也成了AI时代的元年，去年下半年的时候，国内月之暗面出品的Kimi成了新的AI热门，也体验用Kimi修改论文，以及用图片生成代码，代码准确度还是蛮高的。Excel文件成功生成，代码运行成功，但生成内容不全，但已经很不错了，只需微调一下nmap命令参数即可，当然也可以聊天的方式让Kimi自己修改，但不管哪种方式，比之前纯手写速度和准确率都大大提升。Kimi的生成速度很快，相应速度在一分钟以内，还是很不错的。

在互联网业务中，CDN的应用已经成了普遍，SRE的日常需求中，CDN的刷新在前端需求逐渐中占了很大比例，并且比较琐碎。做为合格的SRE，把一切自动化是终极使命，而今天就分享通过Jenkins+Terraform实现阿里云的CDN自动刷新，给大家提供一个自动化思路。

Kubernetes的调度器（kube-scheduler）是整个系统中至关重要的组件，它负责将待调度的Pods分配到合适的节点上。本文将深入分析kube-scheduler的源码，揭示其内部工作机制。

Kubelet作为Kubernetes节点的核心组件，其设计体现了Kubernetes的设计理念：模块化、插件化和可扩展性。通过深入分析Kubelet的源码，我们可以更好地理解Kubernetes节点的运行机制，以及如何定制和扩展Kubelet以满足特定的需求。

问题2：公有云本质上是商业属性，因各自的产品及机房节点布局差异，单个公有云很难完全满足业务需求，但各个云商的一些壁垒限制，多云资源的管理成本又变的较高，尤其是自动化的开发适配成本。Terraform的出现有效的解决了上述问题，它的理念是基础设施即代码，允许用户通过编写代码的方式构建、变更和版本化云基础资源，下面我们先谈谈Terraform的优势。站在SRE的视角，公有云的兴起及大规模普及应用，解决了过去一直无法根本解决的成本和资源快速扩展问题，但同时又衍生出了新的问题。

如果你需要对API请求进行复杂的授权检查，你可以定义一个结构化的授权配置，其中包含多个webhook，并为每个webhook定义特定的验证规则。如果你有一个多容器Pod，其中一个容器特别消耗CPU资源，而另一个容器消耗很少，你可以设置基于该特定容器的资源使用情况来自动伸缩Pod的数量，而不是基于整个Pod的资源使用情况。如果你需要运行一个Pod，并且希望它在Linux用户命名空间中运行，以提高安全性和隔离性，你现在可以在Pod配置中指定用户命名空间，从而确保Pod在一个受限的环境中运行。