- 博客(932)
- 资源 (47)
- 收藏
- 关注
RSS订阅原创 云计算和AI时代，运维应该如何做好转型?
上面我结合一些运维发展到目前的现状以及呈现出的趋势，做了一些分析和建议。最后我们总结一下。新时代下，机遇和挑战并存，我们确实面临着岗位和技能的转型。我给出的建议是:学会写代码，培养产品意识，提升技术运营意识。当然，转型这个过程也不会完全是绝对和极端的，以后就一定是一个运维都不要，一个SA也不要，一个网络工程师也不要。但是，我们应该看到，这些岗位会更加收敛。一个是岗位 设置上会收敛到各大云平台厂商这里，做专职的基础和后端的服务维护;同时随着自动化的完善，在岗位数量上也会收敛，不会再出现大批量的岗位需求。
2022-10-26 20:14:52
746
原创 从谷歌CRE谈起，运维如何培养服务意识?
在讨论一个需求时，如果表达的都是API、缓存、数据库、消息队列等等这些专业术语，估计 业务部门的同学肯定是跟不上我们的思路的，这样的沟通通常无法正常地进行下去，所以就会经常出现业务同学说业务的事情，技术同学说技术的事情，两边不能达成一致，矛盾就 产生了。看问题的角度不同，解决方案也就不一样了。先举个之前我遇到的例子，有个部门给我们提了一个在服务器上安装翻墙软件的需求，结果我们的工程师就照着这个需求去做了，最后发现软件怎么调都启动不了，中间还牵扯到网络同事的配合，需要检查网络上的配置，最后就差动网络设备了。
2022-10-26 15:14:39
1873
1
原创 谷歌SRE运维模式解读
表面看是做稳定的，但是我觉得更好的一种理解方式是，以稳定性为目标，围绕着稳定这个核心，负责可用性、时延、性能、效率、变更管理、监 控、应急响应和容量管理等相关的工作。SRE的能力模型，不仅仅是技术上的，还有产品设计、标准规范制定、事后复盘总结归纳这些技术运营能力，同时还需要良好的沟通协作能力，这个就属于职场软技能。最后，还是我反复强调的观点，要想做好运维，就得跳出运维的局限，要站在全局的角度，站在价值呈现的角度，站在如何能够发挥出整体技术架构运维能力的角度，来重新理解和定义运维才 可以。
2022-10-26 14:39:12
1107
原创 如何打造运维组织架构?
今天我为你介绍了我们正在实践的一些运维组织架构方面的内容。后来当我翻阅《SRE:Google运维解密》这本书时，发现如果按照书中的章节目录进行分类的话，基本上都可以与 前面我介绍的部分对应起来，这也更加坚定了我们要按照这套组织模式运作下去的信心。
2022-10-26 11:12:06
1715
原创 如何在CMDB中落地应用的概念?
通过上述的分析，我们可以看到基于以应用为核心的CMDB中，又衍生出“应用-集群服务分组-资源”这样一个运维体系中的核心关系。经过这三部分的分析，我们之前所说的基于应用为核 心的运维视图就可以建立出来了，我们再次示意如下:今天我们讨论的内容提到了，监控、发布、基础服务以及稳定性平台会依赖CMDB中“应用、集群服务分组-资源”的对应关系信息，但是当CMDB中的这些关系信息发生变化，比如新 增一个IP，或者下线一个IP，这些信息是如何传递到其它平台的呢?这些平台又是如何查询这些关键信息的呢?
2022-10-25 11:49:37
743
2
原创 有了CMDB，为什么还需要应用配置管理?
CMDB是运维的基石，但是要发挥出更大的价值，只有基础是不够的，我们要把更多的精力放到上层的应用和价值服务上，所以我们说应用才是运维的核心。你可以看到，如果仅仅基于CMDB的资源信息作自动化，最多只能做出自动化的硬件资源采集、自动化装机、网络-硬件拓扑关系生成等资源层面的工具，这些工具只会在运维层面产生价值，离业务还很远，就更谈不上给业务带来价值了。但是基于应用这一层去做，就可以做很多事情，比如持续集成和发布、持续交付、弹性扩缩容、稳定性平台、成本控制等等，做这些事情带来的价值就会大大不同。
2022-10-24 20:17:14
580
原创 聊聊CMDB的前世今生
我们前面在讲标准化的时候，对关键的运维对象做了识别，主要分为两个部分:基础设施层面:IDC机房、机柜、机架、网络设备、服务器等;应用层面:应用元信息、代码信息、部署信息、脚本信息、日志信息等。这两部分是整个运维架构的基础部分，运维团队是维护的Owner，需要投入较大的精力去好好地规划建设。
2022-10-24 10:52:09
533
原创 我是如何走上运维岗位的?
在专栏介绍中，我简单分享了自己为什么会走上运维这个岗位，一是责任心使然，出现问题时总是会主动冲在前面解决，另一个是在这个过程中技能提升得很快，很有成就感。不过当时受篇幅所限，并没有完整说明，所以今天我想再来聊一聊这个话题。聊这个话题还有一个出发点，就是当下业界对运维的认知和定位还是存在很多问题的，有不少贬低运维的言论，所以我想结合自己的经历谈谈对这个事情的看法，期望能够带给你一些启发。
2022-10-18 14:36:31
441
原创 如何从生命周期的视角看待应用运维体系建设?
今天我们分析了应用的生命周期，再结合之前讲的标准化内容，我们就找到了做运维架构的切入点，套路也就有了，总结一下就是:从生命周期入手，划分阶段，提炼属性，理清关系，固化基础信息，实现运维场景。同理，这个思路还可以运用到基础设施和基础服务对象的生命周期管理中，虽然它们只是子生命周期，但是具体到每个基础服务上面，同样需要这个管理手段和过程。
2022-10-14 10:32:47
639
原创 标准化体系建设(下):如何建立基础架构标准化及服务化体系?
前面我们一起讨论了为什么要做标准化，标准化的套路是什么，并按照套路进行了基础设施和应用的标准化示例。我想这些内容可以帮助我们举一反三，尝试着应用到实际工作中了。今天，我继续跟你聊基础架构标准化的问题，但是今天我计划不谈如何进行架构标准化的细节，而是想强调一下基础架构标准化的重要性，因为从我个人的经历和我实际观察到的情况来看，这块的问题会更普遍一些，而这一部分又影响着后续一系列效率和稳定性平台的建设方案。
2022-10-13 10:56:13
858
原创 标准化体系建设(上):如何建立应用标准化体系和模型?
今天我专门来讲讲标准化这个工作。可以说这项工作是运维过程中最基础、最重要的，但也是最容易被忽视的一个环节。我做过多次公开演讲，每次讲到这个环节，通常会有单独的一页PPT，就放四个字，字号加大加粗，重复三遍，这四个字就是“标准先行”，然后演讲过程中会大声说出“标准先行，标准先行，标准先行”，重要的事情说三遍，目的就是想反复强调这件事情的重要程度，一定不要忽视。我们运维工作的开展常常不知从何下手，或者上来就冲着工具和自动化去了，却始终不得章法，工具做了一堆，效率却并没有提升。
2022-10-12 10:37:36
951
原创 微服务架构时代，运维体系建设为什么要以“应用”为核心?
今天我来讲一下微服务架构模式下的一个核心概念:应用。我会从这几个方面来讲:应用的起源、应用模型和应用关系模型建模以及为什么要这样做。最终希望，在微服务的架构模式下，我们的运维视角一定转到应用这个核心概念上来，一切要 从应用的角度来分析和看待问题。
2022-10-11 17:09:21
326
原创 为什么Netfix没有运维岗位?
众所周知，Netfix是业界微服务架构的最佳实践者，其基于公有云上的微服务架构设计、持续交付、监控、稳定性保障，都为业界提供了大量可遵从的原则和实践经验。Netfix超前提出某些理念并付诸实践，以至于在国内众多互联网公司的技术架构上也可以看到似曾相识的影子。当然殊途同归也好，经验借鉴也罢，这都不影响Netfix业界最佳实践者的地位。同样，在运维这个细分领域，Netfix仍然是最佳实践的典范。所以专栏的开始，就让我们一起看看世界顶级的互联网公司是如何定义运维以及如何开展运维工作的。
2022-10-11 11:25:46
211
原创 工作区和GOPATH
工作区和 GOPATH 的概念和含义是每个 Go 工程师都需要了解的。虽然它们都比较简单，但是说它们是 Go 程序开发的核心知识并不为过。然而，我在招聘面试的过程中仍然发现有人忽略掉了它们。Go 语言提供的很多工具都是在 GOPATH 和工作区的基础上运行的，比如上面提到的go build、go install和go get，这三个命令也是我们最常用到的。
2022-10-10 20:32:37
338
原创 细谈移动APP的交付流水线（pipeline）
今天，我和你一起分享了移动客户端持续交付流水线的几个详细点：利用发布快车的发布模式，可以有效地管理客户端的版本，保证研发工作按节奏持续向前进展；采用带发布分支的 GitLab Flow 配合发布快车的模型，可以使其做到物理落地；发布快车本身也有一些弊端，比如对 Master 分支的合并，检查不够严格的话，会拖累项目进度，因此我们采用改造构建通道的方式，避免了这个问题的产生；移动 App 的发布，有其独特的流程，通常是先内测，后正式发布；但其流程相对固定，且容易自动化。
2022-10-08 17:12:08
1025
原创 了解移动App的持续交付生命周期
可见，做好项目信息管理在移动 App 的持续交付中尤为重要，而在后端服务的持续交付中却没那么受重视了，这也是移动 App 的持续交付体系与服务端的一大不同点。也就是说，除了从技术角度来看，移动 App 的持续交付会存在依赖管理的内容外，从项目角度来看，也常常会存在功能依赖和功能集成的需要。我在专栏的第四篇文章《一切的源头，代码分支策略的选择》中，和你分享了各种代码分支策略（比如，Git Flow、GitHub Flow 和 GitLab Flow 这三种最常用的特性分支开发模型）的思路、形式，以及作用。
2022-10-08 16:22:53
1029
原创 持续交付中有哪些宝贵数据?
今天我通过三个实际工作中的例子，和你分享了应该如何利用持续交付中产生的数据。首先，你可以利用与业务量相关的数据模型来衡量持续交付系统的稳定性;然后，在日常的数据分析中，除了要抓住主要数据的大趋势外，你还要关注那些异常的个性数据，它能帮你及早地发现问题;最后，通过日常的数据分析，你也能发现持续交付流程上的一些问题，并协助团队一起改进。当然，这只是三个比较突出的例子而已。在实践中，实施持续交付的过程中还有很多数据需要我们关注。我也一并把这些数据分成了三类，包括:1. 稳定性相关指标;
2022-09-28 11:29:42
799
原创 计算资源也是交付的内容
云计算的弹性能力，可以帮助我们改善环境管理模块的能力，使得环境管理的方式更加灵活。比如，原先一个测试子环境的生命周期往往与某个功能研发或是项目研发不一致，会提前准备，或是多次复用;又或者由于资源紧缺的原因，测试环境只能模拟部分实际环境:另外还会有一些环境被作为公共的资源一直保留，从不释放。这些问题都增加了环境管理的复杂度。现在，有了云计算平台的强大能力，我们完全可以打破这些限制，将环境的生命周期设计得与项目生命周期一致，每个项目或每个功能都可以拥有自己独立的测试环境;
2022-09-27 10:39:08
782
原创 持续交付为什么要平台化设计？
平台化”这个词，你应该已经听到过很多次了吧。特别是互联网领域，我们都爱谈论平台化。那么，“平台化”到底是什么意思呢?其实，早在 20 世纪 70 年代，欧洲的军工企业就开始利用平台化的思维设计产品了。当时的设 计人员发现，如果分别研制装甲车、坦克和迫击炮的底盘，时间和金钱成本的消耗巨大。因为这些武器的底盘型号不同，所以它们所需要的模具、零件也就不同，除了要分别设计、制造、测试、生产外，还要花费巨额成本建设不同的生产流水线，而且各底盘的保养和使用方式不同，需要进行不同的人员培训。
2022-09-22 17:18:24
1202
原创 利用Mock与回放技术助力自动化回归
我以提出问题 - 分析问题 - 解决问题的思路，和你展开了今天的分享内容。首先，我和你分享了自动化回归测试会遇到的三个难题:测试数据的准备和清理、分布式系统的依赖，以及测试用例的高度仿真。我们可以利用 Mock 技术(即通过代理的方式模拟被依赖的对象、方法或服务的技术)，通过 不同的框架，解决自动化回归测试的前两个问题:基于对象和类的 Mock，解决一个应用内部依赖的问题;基于微服务的 Mock，解决应用与应用之间外部依赖的问题。
2022-09-22 15:39:59
538
原创 越来越重要的破坏性测试
顾名思义，破坏性测试就是通过有效的测试手段，使软件应用程序出现奔溃或失败的情况，然后测试在这样的情况下，软件运行会产生什么结果，而这些结果又是否符合预期。这里需要注意的是，我们需要使用的测试手段必须是有效的。为什么这样说呢，有两点原因：第一，破坏性测试的手段和过程，并不是无的放矢，它们是被严格设计和执行的。不要把破坏性测试和探索性测试混为一谈。也就是说，破坏性测试不应该出现，“试试这样会不会出问题”的假设，而且检验破坏性测试的结果也都应该是有预期的。
2022-09-22 10:49:46
1977
原创 代码静态检查实践
在分享和你分享代码静态检查实践这个主题时，我分享了近五年国内的大型互联网公司在持续交付实践中摸爬滚打的经验。从这五年的发展实践中，我们可以清楚地看到，越来越多的研发团队把静态检查作为了一个不可或缺的环节，这也确实帮助研发团队提升了代码质量。当然，机器是死的，人是活的，我们千万不要过分迷信静态检查的结果，还要时刻擦亮眼睛，看看是否存在误报等问题。
2022-09-20 10:26:51
2260
原创 如何利用监控保障发布质量？
今天，我围绕着灰度发布的最后一个过程:监控，展开了这次的分享。因为我们这个专栏要解决的主要问题是持续交付，所以我并没有过于详细地阐述如何设计一个监控系统，而只是为你介绍了监控体系的一些基本概念，以及一些与持续交付、持续部署相关的问题。首先，我介绍了监控的几种分类，以及分别可以采用什么方式去采集数据:1. 用户侧监控，可以通过打点收集，或者定期采集日志的方式进行数据收集;2. 网络监控，通过模拟手段或定期采样进行收集;3. 业务监控，需要定义正确的指标以及相匹配的采集技术，务必注意实时性;
2022-09-13 14:24:37
369
原创 业务及系统架构对发布的影响
因为发布系统最终服务的对象是业务应用，所以发布系统的设计除了考虑用户体验，核心架松外，还要注意业务、系统架构对发布系统的影响，并且要合理利用业务、系统架构的能力，去完善发布系统的设计。业务、系统架构对发布系统的影响，主要体现在是选择单机单应用还是单机多应用、选择增量发布还是全量发布这两大方面。在这里，我的建议是简单的才是最好的，即采用单机单应用的部署架构;对于后台应用，以及发布非常频繁的应用来说，全量发布更直接，更容易达成版本控制并做到快速回滚。
2022-09-13 11:19:37
453
原创 发布系统的核心架构和功能设计
我今天分享的主题就是，从后端系统设计的角度，来看看一套发布系统的核心架构和功能应该如何设计。我以携程目前使用的发布系统为例，从发布系统的架构、核心模型、发布流程及状态流转三个方面，展开了今天的分享。首先，高效的发布系统架构应该是清晰的、健壮的、低耦合的，携程在经历各种迭代后，采用了 以 Protal、Controller、Roll Engine、Salt Scripts 为核心的分层架构。...
2022-08-31 11:46:14
1154
原创 发布系统一定要注意用户体验
一路看下来，不知道你是否已经发现，整篇文章的 6 个章节，恰好能用 1~6 这六个数字串接提 炼，我也正是希望这种形式能够加深你对发布系统产品设计的概念理解。这里，我们再一起简单 回顾一下吧。1 张页面展示发布信息，且仅有 1 张页面，展示发布当时的绝大多数信息、数据和内容，这个页 面既要全面，又要精准。2 个操作按钮简化使用，即页面上除了“回滚”按钮常在外，最多同时展示 2 个操作按钮。目的 是要降低发布系统的使用难度，做到“谁开发，谁运行”。...
2022-08-29 11:41:20
565
原创 Immutable！任何变更都需要发布
首先，我分享了“不可变”模型的概念，以及它的由来，介绍了三个非常有价值的模型:发散模型、收敛模型和一致模型。其次，我解释了为什么“不可变”如此重要的原因，也就是重复发散到收敛过程无法解决的三个问题:顺序问题、频率问题和蝴蝶效应。最后，我针对“不可变”及容器，提出了持续交付面对的新问题，即:每一次变更都是一次发布，每一次发布都是一个独立的镜像的启动。...
2022-08-17 10:37:54
155
原创 发布是持续交付的最后一公里
无论是为新需求添加的代码，还是静态配置的变更，线上应用的任何变动都要经过发布这道工序才能最终落地，完成交付。通常，发布意味着应用重启、服务中断，这显然不符合如今系统高可用的需求。同时，软件工程和经验也告诉我们，世界上不存在没有 Bug 的代码，即便经过详尽细致地测 试，线下也很难百分之一百地复制线上的环境、依赖、流量，更难穷举千变万化的用户行为组合。于是，发布变更，在许多时候是一件被标记为“高风险系数”的工作，工程师和测试人员经常在深夜搞得筋疲力尽，甚至焦头烂额。...
2022-08-11 16:37:01
170
原创 如何做好容器镜像的个性化及合规检查?
我们允许用户在编译后的代码包内放入包含自定义环境脚本的 .paas 目录(这是一个自定义的隐 藏目录)，来满足用户对环境的个性化需求。这个.paas 目录中，可能会存在 build-env.sh 和 image-env.sh 两个文件，分别运行于构建代 码和构建镜像的过程中。其中，build-env.sh 是在构建代码之前运行，image-env.sh 是在构建镜像的时候插入到我们规 范的 Dockerfile 中，从而被打到容器内部。...
2022-08-11 14:19:05
736
原创 容器镜像构建的那些事儿
在虚拟机时代就有镜像的说法，当我们创建一个虚拟机时，通常会去网上下载一个ISO格式的虚拟机镜像，然后经过VirtualBox或者VMware加载，最终形成一个包含完整操作系统的虚拟机实例。而容器镜像也是类似的意思，只不过它不像虚拟机镜像那么庞大和完整，它是一个只读的模板，一个独立的文件系统，包含了容器运行初始化时所需要的数据和软件，可以重复创建出多个一模一样的容器。容器镜像可以是一个完整的Ubuntu系统，也可以是一个仅仅能运行一个sleep进程的独立环境，大到几G小到几M。而且。...
2022-08-11 11:03:34
452
原创 构建资源的弹性伸缩
我主要介绍了几种流行的持续集成工具，以及基于Jenkins的高可用构建系统的一些基本设计理念和我们系统的演变过程。1.通常建议使用成熟的CI产品(比如，TravisCl、Circle CI、JenkinsCI)来作为平台的基础;2.虽然这些CI工具是成熟产品，但面对日新月异的技术需求，高可用和伸缩问题还是要自己解决;3.通过请求分发等设计，可以实现Master节点的横向伸缩及高可用问题;4.利用容器技术，可以解决Salve节点的弹性伸缩和资源利用率问题。...
2022-08-10 10:57:42
422
原创 构建检测，无规矩不成方圆
Maven Enforcer 插件提供了非常多的通用检查规则，比如检查 JDK 版本、检查 Maven 版本、 检查依赖版本，等等。下图所示就是一个简单的使用示例。上述的配置会在构建时(准确的说是在 validate 时)完成三项检查:requireMavenVersion 检查 Maven 版本必须大于 3.3.9;requireJavaVersion 检查 JDK 版本必须大于等于 1.9;requireOS 检查 OS 必须是 Windows 系统。...
2022-08-09 15:59:09
1038
原创 如何做到构建的提速，再提速
我介绍了五种常见的构建提速的方式，分别是:1.升级硬件资源，最直接和粗暴的提速方式;2.搭建私有仓库，避免从外网下载依赖;3.使用本地缓存，减少每次构建时依赖下载的消耗;4.规范构建流程，通过异步方式解决旁支流程的执行;5.善用构建工具，根据实际情况合理发挥的工具特性。然而，每个公司持续交付的构建流程不太一样，面临的问题与挑战也都不太一样，所以在优化前，一定要先了解问题原因，再对症下药。...
2022-08-09 14:56:44
332
原创 容器技术真的是环境管理的救星吗?
在传统模式下的开发到部署流程是这样的:1. 在本地电脑上安装开发应用所需要的库文件、扩展包、开发工具和开发框架，完成开发工 作;2. 本地开发完成后，将开发好的应用部署到测试环境进行测试;3. 一切就绪后，再把应用部署到生产环境。但问题是，你该如何保证开发、测试和生产这三套环境，甚至更多套环境是完全一致的呢?再有就是，环境的变更问题，虽说“百分之九十九的故障是由变更导致的”是一句废话，但也是一句实话，你又该如何确保每套环境的变更是一致的呢?而容器的出现，似乎解决了这些问题。......
2022-08-09 14:54:56
114
原创 极限挑战，如何做到分钟级搭建环境?
对于如何快速搭建一套环境，我从虚拟机环境准备、应用部署流水线和环境变更，这三个方面给你总结了一些常见问题和原则:1. 可以使用虚拟机资源池，提升获取机器资源的速度;2. 合理打造并行的应用部署流水线，是进一步提升环境创建速度的方法;3. 利用配置等方式快速达到环境变更需求，可以再次有效地提升整个环境部署的效率。...
2022-08-08 20:13:54
89
原创 “配置”是把双刃剑，带你了解各种配置方法
很多人分不清配置和配置管理，但其实它们是完全不同的概念。配置管理:是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。它的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期的各个阶段都能得到精确的产品配置信息。配置:是指独立于程序之外，但又对程序产生作用的可配变量。也就是说，同一份代码在不同的配置下，会产生不同的运行结果。从上面的定义中，你可以看到配置和配置管理有着本质上的不同:配置管理服务于软件研发过程，而配置则服务于程序本身。...
2022-08-04 14:49:18
471
原创 让环境自己说话，论环境自描述的重要性
我主要围绕环境配置的问题，讲了它的内容和一些特性，以及简化和优化的一些方案。一定要意识到，环境配置是非常复杂的，直接影响你的环境治理能力，而环境治理能力又直接影响着持续交付的能力。但是我们还是可以通过标准化、约定、自描述等方式去简化和优化环境配置工作。我们的目标是，让环境自己能说话。...
2022-08-02 11:16:41
139
原创 测试环境要多少?从成本与效率说起
流程成本主要包括沟通成本和测试成本两个方面。沟通成本每增加一套环境，你都需要考虑团队成员如何在新环境上沟通协作。谁在占用，何时退出这些信息，你都需要第一时间告知团队。当环境的数量变得非常多以后，做好这些事的难度就很大了。测试成本在开发环境，集成测试环境，验收测试环境，预发布环境，生产环境这样的结构下，核心功能的测试流程就至少会执行五次。每引入一套新的环境，测试流程都会变得更加复杂。我们究竟需要多少套环境，这个问题的答案应该是这样的https。......
2022-08-01 18:48:50
273
原创 测试环境要多少，从现实需求说起
在和你分享什么是好的测试环境前，建议你先思考一下开发环境、功能测试环境、验收测试环境、预发布环境这四种测试环境形成的原因是什么，这样有利于你更好的理解好的测试环境的含义。首先，搭建测试环境的目的是保证最终交付的软件质量，但每套测试环境的用户并不完全一样1.开发环境的用户是开发同学;2.功能测试环境的主要用户是测试同学;3.验收测试环境的用户是产品经理和测试同学;4.预发布环境的使用者是测试同学，但收益者却是运维同学。而每种角色对于产品研发流程中的需求也是不同的1.开发同学关注研发效率;...
2022-07-29 11:09:41
248
原创 “两个披萨”团队的分支管理实践
我介绍了由6人组成的“两个披萨”团队代码管理的实践，通过周一到周五的具体活动，你可以看到采用特性分支开发的团队是如何创建分支、集成分支和删除分支的，希望能对你的日常工作也有所帮助。httpshttps。...
2022-07-28 20:41:44
678
2018全新无限流量卡充值官网PHP源码
2019-03-20
http协议-破冰-基础课程
2022-06-22
xlggg-http-notification-master.zip
2019-08-22
后台模板.7z
2019-08-22
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人