不知道运维在忙什么

前段时间,我从领导那里得知,有其他团队的人说:“不知道运维在忙什么”。我懒得打听是谁说的,所以就暂时把这个“谁”称为:说话人。 而我作为运维的 leader,很早前就预料到有人会说这句话。在我自己看来,就两种情况:有人想搞运维团队(坏),或者那个人太不懂职场(菜)。 为了避免我个人情绪,我问了一下 AI:“有人向领导说这话”是什么含义,得到的答案是: “不知道运维在忙什么”通常不是中性询问,而是在领导面前暗示: - 运维工作不透明; - 运维没有及时响应; - 运维可能没做出成果,甚至“瞎忙”。 这是一种比较隐晦的负面评价。尤其当对方没有先向运维了解情况、也没有指出具体事项,却直接在领导面前说,确实带有甩锅、质疑或贬低的意味。 不论是哪种答案,本质上并不是我预料有人会说这句话,而是预料到信息不透明、话语权不对等的情况,发生这样的事情,我觉得是必然的。 我在世界500强、初创公司、上市公司、跨国公司待过,我见过一些世面了。 因此,我管理团队时,选择通过看板管理来公开团队的所有工作,一方面管理自己的团队,一方面预防在出现“情况”时,好有数据来自证。我统计了引入 AI 工具后,最近半年我们完成的工作量提高了 40% 多。 既然,运维团队公开了所有的工作,为什么还有人说不知道运维在忙什么?有几种可能: 说话人没有看,或者没有心思主动去看我们的工作。 运维团队没有同步到位。 情况1,没有什么好说的,大家都是成年人。 关于情况2。运维团队每天都会在看板前进行站会。 当其他团队来找运维团队提需求后,运维团队要多久向其他团队的人同步呢?要运维团队每打一个字就同步吗?当然不是,而是根据不同的团队的“同步频率需求”,来同步。 但是,反过来想,站在公司整体经营成本的角度来想,与其让运维团队花成本来解决“同步”的问题,不如其他团队主动问一句运维团队,这样是不是成本更低?我懒得深究这个情况了。 最终,我开发了一个 bot。v1 版本有2个功能: 只要有人在公司群里发:@infra 在忙什么,bot 就会把运维团队看板上所有 doing 的任务都列出来。 @infra subscribe <ticket> 就可以订阅任何一张卡的状态变更通知。我们运维也不用思考要多久同步,你关心就自己订阅。 这个 bot 只是为了堵住说话人的口,也是职场上的一种正面的回应。 本来,本文就应该停止了。好奇心让我深入思考了这类事件的背后。本质就是话语权不对等的结果,是不同成员影响决策、定义问题和表达异议的能力不平等。 假设软件工程会经过以下流程: 产品经理 -> 设计 -> 开发 -> 运维 -> 测试 这个流程中,谁有向上说话的权力,谁就有权力判定下游工作。假如开发有向上级说话的权力,当开发说:目前卡在运维。 那么,说一次还好,每次开发都这么说。信息传到上级的意思就是:运维工作不行。把“运维”换成“测试”,结果是一样的。 但是,我知道的是,当上级预期是10天完成上线时,而开发占用了9天,留给运维和测试的时间只有1天,也就是最后一天才通知运维要进行上线工作。那么,我们会如何看待开发,以及开发说的“目前卡在运维”呢? 这里只是以开发角色举例,换成其它角色,同样的问题。 那么,我们应该如何解决“话语权不对等”所带来的问题呢?是让话语权平等吗?我也不知道答案。我会继续研究下去。 最后,希望世界和平。

2026-08-22 · 1 min · 59 words · 翟志军 Jack Zhai

什么是手工运维

一个夏天的午后,知了嘈杂,窗下的我 review AI 写好 IaC 代码后,敲下部署到线上环境的命令。 看着终端的日志滚动,一个问题突然蹦入我的大脑:什么是手工运维? 像我这样使用 IaC 来管理基础设施: 过去是手打代码,这算吗? 现在是 AI 写的代码了,但是 prompt 依然是手打,这算吗? 代码是 AI 写了,但是执行,还是需要手工的,这算吗? 如果不使用 IaC,改成使用 GUI,人们可以在界面上点一下“部署”按钮,就完成了整个服务的部署,这算不算手工运维呢? 像 Cloudflare 或者 Vercel 上,开发者都不用点,只需要将写好的业务代码 push 到远程的 git 仓库就可以了,部署和自动化的域名都给自动化完成了,这算不算手工运维呢? 先说结论:不论是使用 GUI 还是 IaC,如果无法做到自动编排部署任务,都是手工运维。 过去,运维人员通过 SSH 一条条命令的输入到服务器,大家都认为那是手工运维。但是,如果把这些命令写成 bash 脚本,可以一键执行,这算自动化运维了吗? 现在,人们在 GUI 界面上,一个个按钮的点击界面,最后点击“部署”按钮,我认为这与通过 SSH 一条条命令运维没有什么区别,也是手工运维。只不过 GUI 的动作的粒度比 SSH 命令大一些。 本质上,以上两种方式,都需要人工编排部署任务,也就属于手工运维。 而 Cloudflare 或者 Vercel。单服务时,不需要编排部署,所以人们觉得自动化运维。但是如果是多个服务,Cloudflare 或者 Vercel无法做到自动化编排部署任务,它依然是手工运维。 所以,使用 IaC 来管理基础设施,算手工运维吗?取决于你的 IaC 代码:当人表达意图后,它能否自动输出部署计划,并且能自动化运行。 如何做到?这是另一个话题了。 希望这篇文章给你带来启发。多谢。

2026-07-10 · 1 min · 63 words · 翟志军 Jack Zhai

使用Ansible实现自动化运维的一些技巧

提示:本文要求读者有一定的 Ansible 使用经验 最近一年才有机会在生产环境上使用 Ansible。用的过程中,想把一些小技巧记录下来,避免自己忘记。如果能帮助到其他同学就更好了。如果有同学指出有更好的方法,就更更好了。 技巧1:校验你的模板文件是否正确 通常我们会使用template module 来生成应用的配置,比如生成 Nginx 的配置或者 sudoers 配置。而像 sudoers 文件内的配置错误可能直接导致无法登录。所以,我们希望在生成这些配置文件后能校验一下它的正确性。如果校验失败,直接停止,不生成该配置文件。 而 template module 有一个属性 validate 就是为了实现这一需求的: - template: src: "user-sudoers" dest: "/etc/sudoers.d/abc" validate: visudo -cf %s 校验 Nginx 配置文件的文件: - name: Copy the nginx file template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf validate: "/usr/sbin/nginx -t -c %s" notify: - restart nginx 校验 Prometheus 配置文件: - name: Copy Prometheus config template: src: prometheus.yml.j2 dest: "/etc/prometheus.yml" validate: "promtool check config %s" notify: reload prometheus config 校验 Logstash 配置文件: ...

2018-06-22 · 2 min · 273 words · 翟志军 Jack Zhai

一些小团队的自动化运维实践经验

注:本文要求读者对Ansible和 Jenkins有一定的认识。 题记: 幸福的家庭都是相似的 不幸的家庭各有各的不幸 行业内各巨头的自动化运维架构都各种功能各种酷炫,如下图,让人可望不可及。现在最终的样子大家都知道了,但问题是如何根据自己团队当前的情况一步步向那个目标演进? 笔者所在团队,三个半开发,要维护几十台云机器,部署了十来个应用,这些应用90%都是遗留系统。应用系统的编译打包基本在程序员自己的电脑上。分支管理也清一色的 dev 分支开发,测试通过后,再合并到 master 分支。生产环境的应用配置要登录上具体的机器看才知道,更不用说配置中心及配置版本化了。 对了,连基本的机器级别的基础监控都没有。 我平时的工作是 50% 业务开发,50% 运维。面对这么多问题,我就想啊,如何在低成本情况下实现自动化运维。本文就是总结我在这方面一些经验和实践。希望对读者有帮助。 别说话,先上监控和告警 事情有轻重缓急,监控和告警是我觉得一开始就要做的,即使业务开发被拖慢。只有知道了当前的情况,你才好做下一步计划。 现在市面上监控系统很多:Zabbix、Open-Falcon、Prometheus。最终作者选择了 Prometheus。因为: 它是拉模式的 它方便使用文本方式来配置,有利于配置版本化 插件太多了,想要监控什么,基本都会有现成的 以上三者,我基本都要重新学,我为什么不学一个 Google SRE 书上推荐的呢? 之前我们已经介绍过,人少机器多,所以,安装 Prometheus 的过程也必须要自动化,同时版本化。笔者使用的是 Ansible + Git 实现。最终样子如下: 这里需要简单介绍一下: Prometheus Server 负责监控数据收集和存储 Prometheus Alert manager 负责根据告警规则进行告警,可集成很多告警通道 node-exporter 的作用就是从机器读取指标,然后暴露一个 http 服务,Prometheus 就是从这个服务中收集监控指标。当然 Prometheus 官方还有各种各样的 exporter。 使用 Ansible 作为部署工具的一个好处是太多现成的 role 了,安装Prometheus 时,我使用的是现成的:prometheus-ansble 有了监控数据后,我们就可以对数据进行可视化,Grafana 和 Prometheus 集成得非常好,所以,我们又部署了 Grafana: 在 Grafana 上查看 nodex-exporter 收集的数据的效果图大概如下: 可是,我们不可能24小时盯着屏幕看CPU负载有没有超吧?这时候就要上告警了,Promehtues 默认集成了 N 多告警渠道。可惜没有集成钉钉。但也没有关系,有好心的同学开源了钉钉集成 Prometheus 告警的组件:prometheus-webhook-dingtalk。接着,我们告警也上了: ...

2018-06-07 · 3 min · 490 words · 翟志军 Jack Zhai

阿里云经典网络下如何节约公网 IP 费用

想法 历史原因,我们一直使用的是阿里云经典网络的 ECS,疲于业务的开发及人力不足,一直没有特别大的动力迁移到 VPC 下。 而经典网络下的 ECS 的公网 IP 是收费的,而且没有公网 IP 有时会不方便。 购买公网 IP 时的费用 未购买公网 IP 时的费用 如果是按月购买,每个月将节约:296 - 273 = 23 元。 而我们的大多服务是内网使用的,所以,公网 IP 的申请完全是浪费。 可是,我们有时,还是需要公网下载一些东西的。这时怎么办呢? 我的方案是:没有公网 IP 的机器,使用 HTTP 代理就可以上网了。 当然,哪些机器需要上网,基于安全上的考虑,需要读者自己决定了。 怎么做? 我的具体实现方便使用 Squid 搭建 http proxy 服务。其他机器通过配置环境变量配置,笔者是通过 Ansible 初始化机器时配置的: - name: use httpproxy lineinfile: path: "/etc/profile" line: "<<item>>" with_items: - "export http_proxy=http://<< httpproxy.host >>:<< httpproxy.port >>/" - "export https_proxy=http://<< httpproxy.host >>:<< httpproxy.port >>/" when: is_use_httpproxy is defined and is_use_httpproxy == 'True' tag: httpproxy 关于 Squid Http Proxy 服务,笔者同样是使用 Ansible 搭建,具体不细表,看官可以自行看代码:Squid-ansible。 ...

2018-05-14 · 1 min · 109 words · 翟志军 Jack Zhai

出现运维事故后,你会怎么办?

从聊天说起 有一次和朋友聊天,他说他们有一次部署出事了,影响还挺大,那次事故后,他们公司对于部署流程增加了更多的审批。 当朋友说完前半句时,我已经猜到下半句,那是很多公司或个人会做出的反应。至于为什么会做出这样的反应,我也不知道。 我问:为什么那次部署会“出事”? 他说:当时部署的人忘记了那台机器上有一条 Iptable 规则,导致了事故。 我就在想,如果有人审批,那次事故就不会发生吗?审批的人就知道那台机器上有一条规则导致事故的发生?然后驳回这次部署吗?连一线的开发和运维都忘记了的 Iptable 规则,“高高在上的审批领导”就更不知道了。 题外话:增加审批流程并不能避免这次事故,只不过当出现事故时,可以更好的定责。然而我又好奇了,这种“审批”是为了解决问题,解决什么问题?,还是为了逃避责任?谁逃避了责任?谁又有责任? 对于这类问题,我心里已经有数了,但想知道这位朋友的回答,就接着问:那么怎么杜绝这类问题呢? 他说:因为那条 Iptable 规则的设置太久远了,是谁都记不起。如果能把每次部署的步骤记录下来,这样下次部署的时候,过一下以前的部署记录,就会知道那个 Iptable 规则了。(作者:大概原意,已经记不清原话) 这位朋友说的做法,我之前待的一个团队的做法也差不多:会有一个页面专门记录下每次部署的步骤,步骤由开发人员写,然后由运维人员执行。只是我不知道他们会不会回顾之前所有针对这台机器的部署步骤。 这个团队里有某某大型互联网公司来的架构师和某财务软件公司来的运维,所以,我不负责地推测,我们这个行业很多公司对于配置的管理还没有达到足够的重视,也没有正确的看待。 我笑了,接着问朋友:那我要知道当前机器的“最终状态”,是不是要找出所有部署记录,还要过滤出对这次部署有影响的每一个细节?比如那条 Iptable 规则。 接下来的对话细节已经记不清,也不重要了。重要的是找出针对这类运维事故根本原因及解决办法。 我个人认为这类问题的根本原因在于: 配置管理的失控: 已经没有人完整知道线上环境配置是什么了?要了解时,只能一个个查。 测试环境与生产环境的配置不一致: 如果那位倒霉的同学在测试环境部署出现这样的问题,到生产环境部署时,自然就会注意相关配置项了。 以上只是我个人认为的,不一定正确,欢迎各位读者讨论。 那如何杜绝这类问题呢? 这两个原因可以看作一个,也可以看作两个。但方法都是一样的: 使用声明式的配置管理方法,而不是脚本式 版本化这些声明的配置 所有环境使用同一套装配置管理方法 使用声明式的配置管理方法,而不是脚本式的 脚本式的配置管理是这样的: apt-get install build-essential apt-get install libtool cd /usr/local/src wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.37.tar.gz tar -zxvf pcre-8.37.tar.gz cd pcre-8.34 ./configure make make install 而声明式的配置管理是这样的: # ./ansible-nginx/tasks/install_nginx.yml # 使用这个7-0.el7版本的yum包 - name: NGINX | Installing NGINX repo rpm yum: name: http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm # 当前机器的nginx的状态应该是最新版本 - name: NGINX | Installing NGINX yum: name: nginx state: latest # 当前机器的 nginx service 的状态应该是已经启动的。至于如何确保 nginx 这个 service,当前是什么状态的,又是如何启动的,我们不需要关心。 - name: NGINX | Starting NGINX service: name: nginx state: started 声明式的配置里写的是当前环境的“状态”,语意上,声明式的配置不论你执行多少次,你得到最终的“状态”就是你所声明的,这也就实现了《持续交付》里说的: ...

2018-03-30 · 1 min · 135 words · 翟志军 Jack Zhai