Skip to content

필사 모드: 隔离网络 Kubernetes 的 Day 2 运维 — 阻止集群因证书到期而死掉的方法

中文
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 隔离网络集群大多是被证书弄死的

隔离网络集群的故障处理做过几次之后,就能看出规律。华丽的故障反而少见。压倒性多数是这样的形态。

去年搭好、一直跑得好好的集群,某一天 kubectl 不通了。错误是一行跟证书有关的消息。想去搜索,可是没有互联网。内部 Wiki 上只有搭建流程,没有续期流程。搭建的人已经离职了。API Server 起不来,所以日志也没法用 Pod 日志的方式看。

这个场景的原因永远都一样。证书是一年期的,而在那一年里谁都没有重启过集群。如果是能上网的环境,这个问题最终也能靠搜几次解决掉,但在隔离网络里恢复要花上好几天。

这篇文章讲的是安装之后第二天开始的事。验证基准如下。

项目确认的值确认时点出处
kubeadm 客户端证书默认 1 年2026-07-31kubeadm certs
kubeadm CA 证书默认 10 年2026-07-31kubeadm certs
k3s 客户端与服务端证书365 天,重启时若距到期 120 天以内则自动续期2026-07-31k3s certificate
k3s 自动续期阈值的变更2025 年 5 月发布之前是 90 天2026-07-31k3s certificate
k3s 快照默认保留个数52026-07-31k3s etcd-snapshot

证书 — 检测在先,续期在后

比背下续期命令更重要的,是提前知道到期正在逼近这件事。到期当天才知道续期命令没什么帮助。那时候服务已经停了。

检测

kubeadm 集群里有专用命令。

# 在控制平面节点上
sudo kubeadm certs check-expiration

输出里会显示每张证书的到期日与剩余时间、签名的 CA,以及它是不是由外部管理的证书。重要的是,kubelet 客户端证书在这个输出里不会出现。官方文档说明,kubelet 客户端证书由自动轮换管理,并且单独放在 kubelet 目录下面。得另外去看。

# kubelet 证书要单独确认
sudo ls -la /var/lib/kubelet/pki/
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -enddate

k3s 有专用的子命令。可以指定输出格式,很方便放进脚本里。

sudo k3s certificate check --output table

而且 k3s 在到期临近时会留下 Kubernetes 事件。按官方文档,原因(reason)是 CertificateExpirationWarning,并且挂在对应的节点上。把这个事件接成告警,检测就自动化了。

# 查询到期警告事件
sudo k3s kubectl get events -A --field-selector reason=CertificateExpirationWarning

建议放一个与发行版无关都能跑的检测脚本,挂到 cron 上。隔离网络里没有外部监控 SaaS,所以这个脚本事实上就是唯一的早期预警。

#!/usr/bin/env bash
# cert-watch.sh — 每天执行。距到期 60 天以内就用非正常退出来告警。
set -uo pipefail
THRESHOLD_DAYS=60
NOW=$(date +%s)
WARN=0

check_pem() {
  local f="$1"
  [ -f "${f}" ] || return 0
  local end epoch left
  end=$(openssl x509 -in "${f}" -noout -enddate 2>/dev/null | cut -d= -f2) || return 0
  epoch=$(date -d "${end}" +%s 2>/dev/null) || return 0
  left=$(( (epoch - NOW) / 86400 ))
  if [ "${left}" -lt "${THRESHOLD_DAYS}" ]; then
    echo "WARN  剩余 ${left}${f}  (${end})"
    WARN=$((WARN+1))
  else
    echo "ok    剩余 ${left}${f}"
  fi
}

# kubeadm 系
for f in /etc/kubernetes/pki/*.crt /etc/kubernetes/pki/etcd/*.crt; do
  check_pem "${f}"
done
# kubelet
check_pem /var/lib/kubelet/pki/kubelet-client-current.pem
# k3s 系
for f in /var/lib/rancher/k3s/server/tls/*.crt; do
  check_pem "${f}"
done

echo "警告 ${WARN} 件"
exit "${WARN}"

kubeadm 集群的续期

kubeadm 有一个在实务上非常重要的性质。执行 kubeadm upgrade 会自动续期所有证书。也就是说,会定期做升级的集群几乎不会遇到证书问题。隔离网络集群因证书而死的理由也在这里。因为带入审批而不做升级,于是也就没有续期的机会。

手动续期如下。

# 全部续期
sudo kubeadm certs renew all

# 也可以单个续期
sudo kubeadm certs renew apiserver
sudo kubeadm certs renew admin.conf

官方文档明确写着一条重要的注意事项。手动续期之后必须自己去重启控制平面组件。kubeadm 不会替你重启。只做了续期却忘了重启,就会变成命令成功了但服务依然握着旧证书的状态。

# 让静态 Pod 重启的最简单方法 — 把清单挪走一下再放回来
sudo mkdir -p /tmp/kube-manifests
sudo mv /etc/kubernetes/manifests/*.yaml /tmp/kube-manifests/
sleep 20
sudo mv /tmp/kube-manifests/*.yaml /etc/kubernetes/manifests/

# 让新的 admin.conf 生效
sudo cp /etc/kubernetes/admin.conf "${HOME}/.kube/config"
sudo chown "$(id -u):$(id -g)" "${HOME}/.kube/config"

# 确认
sudo kubeadm certs check-expiration
kubectl get nodes

如果想延长有效期本身,就在集群配置里指定。在隔离网络这种重启机会稀少的环境里,这值得考虑。

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
certificateValidityPeriod: 8760h # 默认 365 天
caCertificateValidityPeriod: 87600h # 默认 3650 天

值使用 Go 的 duration 格式,支持的最大单位是小时。不过延长有效期就等于放慢轮换周期,所以请先确认它跟安全策略不冲突。另外使用外部 CA 的情况下 kubeadm 无法管理证书。这种情况下必须用 kubeadm certs generate-csr 生成 CSR 拿到外部去签名,续期完全是手动的。

k3s 的续期

k3s 在服务重启时会自动续期距到期 120 天以内的证书(2025 年 5 月发布之前是 90 天)。这个动作的方式是复用既有的密钥,只延长有效期。

# 诱发自动续期的最简单方法 — 重启
sudo systemctl restart k3s

# 显式轮换
sudo systemctl stop k3s
sudo k3s certificate rotate
sudo systemctl start k3s

# 只轮换特定服务
sudo k3s certificate rotate --service api-server,etcd,kubelet

可轮换的服务名在官方文档里列举为 admin、api-server、controller-manager、scheduler、k3s-controller、k3s-server、cloud-controller、etcd、auth-proxy、kubelet、kube-proxy。

CA 是另一回事。k3s 在首次启动时生成的自签名 CA 有效期 10 年,而且不会自动续期。轮换有专用的命令。

# 自签名 CA 轮换 — 用交叉签名维持信任链
# (脚本必须在带入时一起带进来。隔离网络里没法用 curl 取。)
sudo bash /opt/staging/rotate-default-ca-certs.sh
sudo k3s certificate rotate-ca --path=/var/lib/rancher/k3s/server/rotate-ca
# 换成内部 CA 的情况 — 在单独的目录里准备好之后再应用
sudo k3s certificate rotate-ca --path=/opt/k3s/server
# 应用后要在所有节点上重启 k3s。
# 要换掉根 CA 本身则需要 --force,并且必须先重设已加入节点的 token。

rotate-default-ca-certs.sh 是放在 k3s 仓库里的脚本。隔离网络里无法从互联网获取,所以必须放进最初的带入清单。它是那种等到需要的时候才发现没有的典型项目。

时间与名字 — NTP、内部 DNS、OS 软件包镜像源

证书之后,第二个悄悄压垮隔离网络集群的是时间。而且时间问题的症状,从来都不长得像时间问题。

TLS 验证会把证书的生效与失效时刻同当前时刻做比较。节点时钟只要偏差几分钟,就会报出"证书还没有生效"或者"已经过期"的错误。etcd 更敏感。租约到期与领导者选举都基于时间,所以节点之间的偏差一大,领导者就会反复更换,写入延迟跳动,最坏的情况下连法定人数的判断都会动摇。

隔离网络里这个问题特别容易发生,理由很明确。默认的 NTP 配置指向公共 NTP 池,而那在隔离网络里是够不到的。安装当时硬件时钟是准的,所以谁都没察觉,然后在几个月里慢慢拉开。

# 确认当前的同步状态 — 这里是隔离网络点检的第 1 项
timedatectl status
chronyc sources -v 2>/dev/null || ntpq -p 2>/dev/null
chronyc tracking 2>/dev/null
# 固定到内部 NTP 服务器
sudo tee /etc/chrony.d/internal.conf > /dev/null <<'EOF'
server 10.10.10.11 iburst prefer
server 10.10.10.12 iburst
makestep 1.0 3
EOF

# 必须删掉指向公共池的默认配置(路径因发行版而异)
sudo grep -rn "pool\|ntp.org" /etc/chrony.conf /etc/chrony.d/ 2>/dev/null

sudo systemctl restart chronyd
sleep 5
chronyc sources -v
# 一次性查看集群全部节点的时刻偏差
for n in $(kubectl get nodes -o jsonpath='{.items[*].metadata.name}'); do
  printf "%-20s " "${n}"
  ssh "${n}" "chronyc tracking 2>/dev/null | awk '/System time/{print \$4, \$5, \$6}'" || echo "unreachable"
done

内部 DNS 也是同样性质的问题。CoreDNS 会把集群域之外的查询转发给节点的解析器,而那个解析器如果指向够不到的公共 DNS,就会每次查询都等一次超时。症状表现为"慢",而要弄清原因是 DNS 需要花时间。

# 确认 CoreDNS 在看着什么
kubectl -n kube-system get configmap coredns -o yaml

# 节点的解析器
cat /etc/resolv.conf

# 确认内部 DNS 的应答
dig @10.10.10.53 registry.internal.example +short

OS 软件包镜像源不像证书和 NTP 那么急,但没有它的话某一天你会突然什么活都干不了。内核安全补丁、容器运行时的依赖软件包、调试工具(tcpdump、strace、zstd)的安装全都被堵死。搭建隔离网络时请把内部软件包镜像源一起立起来,并且把集群节点配置成只看向它。镜像源自身的同步必须进入定期带入的对象之列。

etcd 备份与演练过的恢复

备份大部分团队都在做。恢复大部分团队都没有做过。在隔离网络里这个差别是致命的。如果第一次执行恢复流程的时点正处在故障的正中间,那你既没法检索文档,也没法向外面提问。

k3s 内置了快照功能。按官方文档,默认值是 12 小时间隔的调度、保留 5 个,保存位置是数据目录下的 db/snapshots。

# /etc/rancher/k3s/config.yaml — 隔离网络推荐配置
etcd-snapshot-schedule-cron: '0 */6 * * *'
etcd-snapshot-retention: 12
etcd-snapshot-compress: true
etcd-snapshot-dir: /var/backups/k3s-snapshots
# 按需快照 — 升级或危险变更之前务必执行
sudo k3s etcd-snapshot save

# 列表与清理
sudo k3s etcd-snapshot ls
sudo k3s etcd-snapshot prune --snapshot-retention 12
sudo k3s etcd-snapshot delete on-demand-node1-1753900000

在隔离网络里还有一个文件必须一起备份。这是官方文档明确警告的项目。那就是 Server token。因为 token 被用于机密数据的加密,所以恢复时没有相同的 token 值就用不了快照。

# 把快照和 token 当作一套来保管
sudo install -m 0600 /var/lib/rancher/k3s/server/token \
  /var/backups/k3s-snapshots/token-$(date +%Y%m%d)

# 把备份集推到集群之外的存储(比如隔离网络内部另外的 NAS)
sudo rsync -a --delete /var/backups/k3s-snapshots/ backup-nas:/k3s/prod/

下面是恢复流程。这套流程请每个季度在暂存环境里实际执行一遍。读过和做过是两回事。

# 单台 Server
sudo systemctl stop k3s
sudo k3s server \
  --cluster-reset \
  --cluster-reset-restore-path=/var/backups/k3s-snapshots/etcd-snapshot-node1-1753900000
# 上面的命令打印出完成消息之后用 Ctrl-C 退出,然后
sudo systemctl start k3s
# 多台 Server — 必须守住顺序
# 1) 在所有 Server 上停止 k3s
sudo systemctl stop k3s

# 2) 只在第一台 Server 上执行 cluster-reset 恢复(上面的命令)

# 3) 启动第一台 Server
sudo systemctl start k3s

# 4) 在其余 Server 上删除数据目录 — 漏掉这一步它们就合流不进来
sudo rm -rf /var/lib/rancher/k3s/server/db/

# 5) 启动其余 Server
sudo systemctl start k3s

如果是 kubeadm 集群就直接用 etcdctl。

# 快照
sudo ETCDCTL_API=3 etcdctl snapshot save /var/backups/etcd-$(date +%Y%m%d%H%M).db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# 确认快照的完整性 — 只保存却不确认的团队真的很多
sudo ETCDCTL_API=3 etcdctl snapshot status \
  /var/backups/etcd-*.db --write-out=table

请把恢复演练放进季度日程,并把演练结果记录到文档里。需要记录的不是成功与否,而是花了多长时间以及卡在了哪里。那会成为真实故障时的恢复目标时间。

没有上游的升级 — 暂存包与偏差规则

隔离网络的升级就是"带入新的构件然后替换"。流程本身不难,难的是计划。

最先要确认的是版本偏差策略。控制平面与 kubelet、kubectl 之间允许的版本差每个发布都会更新,所以在制定带入计划之前,请到官方版本偏差策略文档确认目标版本的允许范围,并把那个值明确写进带入计划书里。这个值要是靠记忆去写,必错无疑。

而且控制平面无法跳过次版本号往上升。如果带入审批是一个季度一次,而次版本号在这期间上升了两次,那么一次带入就必须装下两步升级所需的全部构件。不提前做这个算术,就会变成拿到了带入介质却只能升一半的局面。

# 带入计划的核算 — 确认当前版本与目标版本之间的阶段
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}'
kubectl version -o json | jq -r '.serverVersion.gitVersion'

请引入暂存包这个概念。在一个带入介质里装进一轮升级所需要的全部东西,并在其中用清单固定住,让版本不会错开。

/opt/staging/upgrade-2026Q3/
├── VERSION                       # 目标版本一行
├── MANIFEST.sha256
├── step1-v1.35.7/
│   ├── k3s
│   └── k3s-airgap-images-amd64.tar.zst
├── step2-v1.36.2/
│   ├── k3s
│   └── k3s-airgap-images-amd64.tar.zst
├── addons/                       # 这一轮一起升级的附加组件镜像
└── ROLLBACK.md                   # 各阶段的回滚判断基准与命令

升级执行前的检查清单,短了才会真被遵守。

#!/usr/bin/env bash
# pre-upgrade.sh
set -uo pipefail
ERR=0

echo "[1] 快照"
sudo k3s etcd-snapshot save || ERR=$((ERR+1))

echo "[2] token 备份"
sudo cp /var/lib/rancher/k3s/server/token "/var/backups/token-$(date +%Y%m%d%H%M)" || ERR=$((ERR+1))

echo "[3] 打包完整性"
(cd /opt/staging/upgrade-2026Q3 && sha256sum -c MANIFEST.sha256) || ERR=$((ERR+1))

echo "[4] 节点状态"
kubectl get nodes --no-headers | grep -v " Ready " && ERR=$((ERR+1))

echo "[5] PodDisruptionBudget"
kubectl get pdb -A

echo "[6] 证书剩余期限"
sudo k3s certificate check --output table

echo "错误 ${ERR} 件"
exit "${ERR}"

升级本身就是换归档包和换二进制文件。这时候旧的归档包必须删掉。留着的话镜像目录里会共存两个版本,变成难以预测的状态。

sudo systemctl stop k3s
sudo rm -f /var/lib/rancher/k3s/agent/images/k3s-airgap-images-amd64.tar.zst
sudo rm -f /var/lib/rancher/k3s/agent/images/.cache.json
sudo cp /opt/staging/upgrade-2026Q3/step2-v1.36.2/k3s-airgap-images-amd64.tar.zst \
  /var/lib/rancher/k3s/agent/images/
sudo install -m 0755 /opt/staging/upgrade-2026Q3/step2-v1.36.2/k3s /usr/local/bin/k3s
sudo systemctl start k3s
sudo k3s kubectl get nodes -o wide

没有 SaaS 的可观测性与可带出的支持包

在隔离网络里,可观测性栈也必须全部待在内侧。既没有远程写入的目标,也没有仪表盘市场,更没有告警的接收方。设计时必须决定的有三件事。

第一,仪表盘和规则都是带入物。从 UI 用导入的方式获取 Grafana 仪表盘的路径,在隔离网络里跑不通。请在采集阶段把 JSON 下载下来带进去,再用 provisioning 部署。

# DMZ 采集阶段 — 把仪表盘 JSON 落成文件
mkdir -p dashboards
curl -fL -o dashboards/node-exporter.json \
  "https://grafana.com/api/dashboards/1860/revisions/latest/download"
sha256sum dashboards/*.json >> MANIFEST.sha256
# 隔离网络内部 — 用 provisioning 部署(ConfigMap 挂载方式)
apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-dashboard-provider
  namespace: monitoring
data:
  provider.yaml: |
    apiVersion: 1
    providers:
      - name: airgap
        orgId: 1
        folder: 'Airgap'
        type: file
        disableDeletion: true
        options:
          path: /var/lib/grafana/dashboards

第二,请把告警的接收方定为内部系统。外部的即时通讯或者呼叫 SaaS 是出不去的。实务上剩下的选项也就是内部 SMTP、内部即时通讯的 webhook 端点、内部工单系统 API 这些。三个都没有的话,最后的手段就是在节点上留本地日志然后由人定期查看,可那样就不是告警而是点检了。没有告警通路的可观测性栈只是仪表盘,不是监控。

# Alertmanager — 只走内部 SMTP 出去的配置
route:
  receiver: internal-mail
  group_wait: 30s
  repeat_interval: 4h
receivers:
  - name: internal-mail
    email_configs:
      - to: 'k8s-ops@internal.example'
        from: 'alertmanager@internal.example'
        smarthost: 'smtp.internal.example:25'
        require_tls: false

第三,必须能够生成支持包。在隔离网络里得到厂商或外部专家帮助的唯一办法,就是把诊断所需的信息打成归档包,经过带出审批带到外面去。可是毫无准备就去做的话会出两个问题。要么需要的信息缺了,要么装进了不该带出去的信息而在审批里被驳回。

#!/usr/bin/env bash
# support-bundle.sh — 考虑了带出审批的诊断包
set -uo pipefail
TS="$(date +%Y%m%d-%H%M)"
DIR="/var/tmp/support-${TS}"
mkdir -p "${DIR}"/{cluster,nodes,logs}
K="sudo k3s kubectl"

echo "== 集群资源(不含 Secret)"
${K} get nodes -o wide            > "${DIR}/cluster/nodes.txt" 2>&1
${K} get pods -A -o wide          > "${DIR}/cluster/pods.txt" 2>&1
${K} get events -A --sort-by=.lastTimestamp > "${DIR}/cluster/events.txt" 2>&1
${K} describe nodes               > "${DIR}/cluster/nodes-describe.txt" 2>&1
${K} api-resources                > "${DIR}/cluster/api-resources.txt" 2>&1
${K} version -o json              > "${DIR}/cluster/version.json" 2>&1
# Secret 只取名字 — 值绝对不装进去
${K} get secrets -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,TYPE:.type \
                                  > "${DIR}/cluster/secrets-list.txt" 2>&1

echo "== 只取失败中的 Pod 的日志"
${K} get pods -A --field-selector=status.phase!=Running --no-headers 2>/dev/null \
| while read -r ns name _; do
    ${K} -n "${ns}" logs "${name}" --all-containers --tail=500 \
      > "${DIR}/logs/${ns}_${name}.log" 2>&1 || true
    ${K} -n "${ns}" describe pod "${name}" \
      > "${DIR}/logs/${ns}_${name}.describe" 2>&1 || true
  done

echo "== 节点信息"
uname -a                          > "${DIR}/nodes/uname.txt" 2>&1
free -h                           > "${DIR}/nodes/mem.txt" 2>&1
df -h                             > "${DIR}/nodes/disk.txt" 2>&1
timedatectl status                > "${DIR}/nodes/time.txt" 2>&1
chronyc tracking                  > "${DIR}/nodes/chrony.txt" 2>&1
sudo journalctl -u k3s -n 5000 --no-pager   > "${DIR}/logs/k3s.log" 2>&1
sudo tail -n 5000 /var/lib/rancher/k3s/agent/containerd/containerd.log \
                                  > "${DIR}/logs/containerd.log" 2>&1
sudo k3s certificate check --output table   > "${DIR}/cluster/certs.txt" 2>&1

echo "== 带出前的点检 — 检测 token 与密钥模式"
grep -rIlE 'BEGIN (RSA |EC )?PRIVATE KEY|K10[0-9a-f]{16,}|password:\s*\S+' "${DIR}" \
  > "${DIR}/REDACTION-REVIEW.txt" 2>/dev/null || true
echo "带出之前请务必审阅下面这些文件:"
cat "${DIR}/REDACTION-REVIEW.txt"

tar -czf "/var/tmp/support-${TS}.tar.gz" -C /var/tmp "support-${TS}"
sha256sum "/var/tmp/support-${TS}.tar.gz"
echo "生成完成: /var/tmp/support-${TS}.tar.gz"

最后一步的敏感信息检测请务必加上。要是支持包里混着 Server token 或者私钥出去了,在带出审批里被驳回还算走运,最坏的情况会按安全事故来处理。请在由人用眼睛确认检测结果为空之后,再提交带出申请。

日常、每周、每季度点检表

隔离网络运维里那些无法自动化的东西,终究还是得由人定期去看。划分周期的标准是"这件事被放着不管的话,多久之后服务会停"。

周期点检项目确认命令或方法放着不管会怎样
日常节点 Ready 状态kubectl get nodes工作负载悄悄挤到一边
日常异常的 Podkubectl get pods -A 的状态过滤重试循环吞噬节点资源
日常节点磁盘使用率df -h 与镜像 GC 阈值镜像 pull 不了 — 隔离网络里恢复很慢
日常时刻同步状态chronyc trackingTLS 验证失败与 etcd 不稳定
每周证书剩余期限cert-watch.sh 或者 certificate check到期当天集群停止
每周etcd 快照是否生成以及大小etcd-snapshot ls 与文件大小的走势以为有备份其实没有
每周漏洞库的新鲜度带入台账上最后一次 Trivy DB 的带入日扫描结果变得毫无意义
每周镜像带入台账与实际仓库的比对比较带入日志与仓库的标签列表来路不明的镜像存在于集群中
每月OS 安全补丁的应用以内部软件包镜像源为准的更新列表内核漏洞不断累积
每月base 镜像的重新带入执行带入流水线全部派生镜像共享同一个漏洞
每季度etcd 恢复演练在暂存环境执行 cluster-reset 恢复真出故障时才第一次做
每季度版本升级的带入与应用带入暂存包之后分阶段应用偏差拉大导致一次升不上去
每季度支持包生成的演练执行 support-bundle.sh 并确认带出审批流程出故障时因包的格式被驳回而损失时间
每半年CA 到期确认与轮换计划的检视确认 CA 证书的 enddate10 年后全部集群一次性停止
每半年带入清单与实际使用清单的比对把清单文件与集群镜像列表做 diff搬了不用的,漏了要用的

这张表里最常被跳过的项目是每季度的恢复演练。而那也是真出故障时代价最高的一个。演练可以新建一个集群来做,就算只是把快照在另一台节点上还原一下,也能确认掉相当一部分。

结语 — 隔离网络的运维是在日历上进行的

隔离网络集群的 Day 2 运维里没有太多特别的技术。证书续期的命令也好,快照恢复的流程也好,升级的顺序也好,全都写在官方文档里。可集群还是会死,理由是那些命令没有在需要的时点被执行

在能上网的环境里这个问题不太显现。出了问题就搜索、取工具,几天就恢复了。在隔离网络里同样的问题会变成好几周。所以隔离网络运维的实力,表现出来的不是事故应对能力,而是守住日历的能力

把点检表放进日历、指定负责人、记录演练结果。这三件事分开了因证书到期而死的集群和安静运转五年的集群。

参考资料

현재 단락 (1/281)

隔离网络集群的故障处理做过几次之后,就能看出规律。华丽的故障反而少见。压倒性多数是这样的形态。

작성 글자: 0원문 글자: 14,092작성 단락: 0/281