运维自动化实践：告警治理、自动化巡检与故障复盘

干了几年运维最怕听到两句话一句是“线上好像有点问题你看下”另一句是“这个之前不是你负责的吗”。前者意味着你的周末提前结束后者意味着你的锅已经提前预定。所以当有人在群里甩出“干运维是条不归路”这句话时底下一片“1”我也默默点了个赞——但点完我就去把手上的值班表、告警规则和一键巡检脚本重新捋了一遍。跑路这两个字我理解得比较实在不是拍拍屁股换个工位而是把自己从“人肉救火”的那条路上挪出来挪到一条能积累、能复用、能按时下班的路上。这篇内容就是把这几年踩过的坑、改过的流程、写过的脚本摊开讲适合刚入行一两年、天天被电话叫醒的朋友也适合干了五六年、开始琢磨要不要转岗的老哥。不吹方法论只讲我自己验证过能落地的那部分。1. 先把“不归路”这三个字拆开看1.1 运维为什么会干成一支“救火队”很多人对运维的印象停留在“装机器、重启服务、半夜接电话”。这个印象不全错但它描述的只是运维工种里最原始的那一层人肉执行层。处在这一层你的产出和你的在线时长强绑定你在工位上坐十二个小时价值就是十二个小时你请假三天系统就敢给你表演三天。这种模式最要命的地方在于它不会自己变好——故障越多你越熟练你越熟练故障处理越依赖你越依赖你你越走不开。这就是“不归路”这个说法的真实来源它不是行业诅咒而是角色定位卡在了错误的位置上。我自己最早也是这样。那会儿一台机器起不来我能抱着键盘盯到凌晨三点第二天还沾沾自喜地跟人说“我搞定了”。现在回头看那次故障的价值不在于“我搞定了”而在于“为什么只有我能搞定”。如果这个答案一直是“因为我记得那台机器的脾气”那你就是在给自己挖坑而且挖得挺开心。真正的分水岭出现在你开始问第二个问题的时候这件事能不能写成脚本、写进文档、写进流程让下一个人不用问我也能搞定。所以我不太认同“运维是条不归路”这种绝对化的说法但我完全理解为什么这么多人这么讲。因为这个岗位的默认路径确实通向救火队而跳出默认路径需要主动做功没人会替你安排。你不主动做五年后你还是那个“最熟悉这台机器的人”只不过头衔从初级变成了资深电话还是那些电话。1.2 四种典型的“走岔”方式我把身边见过的情况归了归类大致是四种走向。这四种不是按能力高低排的而是按“时间花在哪儿”排的你可以对照看看自己在哪一格里。类型日常状态短期表现三年后的样子人肉执行型手动登录、手动改配置、手动重启反应快救火及时越来越忙事情越来越多人越来越难请假工具堆砌型装了一堆平台用起来一半汇报材料好看平台没人维护告警照样炸团队信任度下降深度专精型死磕一个方向比如数据库或网络某类问题只有你能解稀缺性高但在小团队里容易被“供起来”而缺少横向空间体系构建型把重复动作沉淀成流程和工具前期见效慢甚至被说“不干正事”团队不再依赖某个人自己有了可迁移的方法论我早期掉进的是第一格后来短暂掉进过第二格——有段时间特别迷恋“上平台”觉得只要工具到位一切迎刃而解。结果装了三个监控、两个发布系统最后一个都没用透告警该响还是响发布该回滚还是回滚。这段经历给我的教训特别朴素工具解决的是“有没有”流程解决的是“顺不顺”人解决的是“愿不愿”。三样缺一样平台就是个摆设。1.3 我给运维价值划的三条线后来我自己琢磨出一个比较土的分法把运维的成长分成三条线你可以拿来当自我检查表用。第一条线能不能让系统跑起来。这是基本功装机、部署、配网络、看日志、定位常见的服务异常。这条线不过关谈什么转型都是空的。第二条线能不能让系统自己跑起来。这里的关键词是自动化、标准化、可重复。同一件事做第二遍就该写脚本做第三遍就该进流程做第四遍还在手动敲那就是在浪费生命。第三条线能不能让系统跑得划算。到这一层就开始算账了资源利用率、故障成本、变更成功率、平均恢复时间。你开始用数字说话而不是用“我感觉最近挺稳的”说话。大部分人卡在第一条线和第二条线之间不是因为不会写脚本而是因为没时间写脚本——时间全花在第一条线上了。这看起来是个死循环其实有解解法在下一节。2. 值班和告警先把自己从“随时待机”里捞出来2.1 告警治理的四条硬规矩如果只能改一件事我建议先改告警。因为告警是你和系统之间唯一的高频通道这个通道一旦失真你对系统的判断就全废了。我给自己团队定过四条规矩执行下来效果比任何工具升级都明显。第一条能被忽略的告警就不该存在。判断标准很简单如果一条告警连续出现十次有八次没人处理那它就不是告警是噪音。噪音的危害不只是烦人它会训练所有人对告警脱敏等到真出事的那一条混在里面没人会当回事。第二条告警必须指向动作而不是指向现象。“CPU 使用率超过 80%”是现象“订单服务 P99 延迟连续五分钟超过 500 毫秒”才是能导向动作的描述。前者你看到之后第一反应是“再看看”后者你会去想是数据库慢查询还是下游超时。第三条分级必须有而且级别要和通知方式绑定。我见过太多团队分级只写在文档里实际通知全发一个群。级别不绑定通道分级就是自娱自乐。第四条告警要有人认领。每条规则背后得有归属模块不然出了事就是“这个我不清楚是谁配的”。按这四条过一遍通常能砍掉三到五成的规则。砍的时候心里会发虚觉得万一漏了呢。我的经验是漏掉的概率远小于噪音造成的注意力损耗而且漏掉的第一次会很快补回来噪音可是天天在消耗你。2.2 值班表怎么排才不散架值班这件事排得好是保障排不好是消耗。我试过三种排法最后稳定下来的是一周一轮、主备双岗、白天重叠。一周一轮太短会频繁切换上下文太长会让人精神紧绷到极限。一周是比较舒服的颗粒度。主备双岗主岗第一响应备岗在主岗十五分钟未响应时接手。这条很关键单岗制最大的问题是“不敢睡”双岗制给了人一个可以闭眼的安全垫。白天重叠交接放在工作日白天两个人对着屏幕过一遍未闭环的问题比在群里发一段文字交接有效十倍。交接内容我固定成四行写在值班文档最上面昨天动了什么、有什么没闭环、有哪些临时绕过的方案、今天重点关注什么。第四行最容易被跳过但它恰恰是判断“今天能不能安心”的关键。临时绕过方案也特别值得记因为绝大多数“莫名其妙又好了”的故障都是上一次绕过留下的雷。注意值班制度最怕的是“名义上有备岗实际上备岗也在忙自己的事”。备岗必须明确写进排期不能靠人情。我吃过这个亏主岗打了六个电话没人接最后是已经下班的同事远程救的场。2.3 告警降噪的一次实操记录说个具体的。之前有个核心接口一天能报两百多条超时告警团队已经麻木了。我花了一个下午做了一次收敛流程是这样的。第一步先把原始数据捞出来看分布。不看不知道两百多条里有接近七成集中在凌晨两点到四点而且是同一个下游依赖的批量任务时段。也就是说绝大部分告警是预期内的资源竞争不是故障。第二步把“瞬时抖动”和“持续劣化”分开。瞬时抖动用单点阈值判断必然误报需要引入持续时间窗口。我把规则从“单次超过阈值”改成“连续三个采集周期都超过阈值”误报直接掉了一半。第三步按业务影响重新分级。影响下单链路的定义为高优直接电话影响报表、日志检索这类旁路功能的定义为低优进日报。同样一条延迟告警落在不同链路上紧急程度差着数量级。第四步把规则写成可版本管理的文件。手点出来的规则最大的问题是没人知道它为什么长这样改也不敢改。写成文件之后每次调整都有记录谁改的、为什么改一眼能看出来。下面是我当时用的一个简化版规则骨架思路是把“阈值 持续时间 分级 通知通道”这四件事绑在一起groups: - name: order-service-latency rules: - alert: OrderApiP99LatencyHigh expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{serviceorder}[5m])) by (le)) 0.5 for: 3m labels: severity: critical owner: order-team annotations: summary: 订单接口 P99 延迟超过 500ms 且持续 3 分钟 runbook: https://internal.example/runbook/order-latency action: 先看下游库存服务 RT再查慢查询最后看连接池占用这段配置里有三个点值得单独说。for: 3m就是前面提到的持续时间窗口它的作用是过滤抖动runbook和action两个注解是给半夜被叫醒的人看的人的记忆在凌晨是不可靠的写在规则里比记在脑子里靠谱owner标签是为了后面做归属统计谁家的告警多谁家的稳定性就该被拿出来聊。阈值怎么定很多人凭感觉。我的做法是拿最近三十天的真实数据算分位数取 P99 作为基线再上浮百分之二十到三十作为告警线。比如这个接口三十天的 P99 是 380 毫秒那 500 毫秒就是个合理的位置——它明显高于日常水平又没高到要等系统彻底卡死才报警。这个算法不精密但它有依据比拍脑袋强。3. 把重复动作变成资产自动化和平台化3.1 自动化该从哪三件事下手一提自动化很多人脑子里想的是“搞个平台”。这个念头很危险因为平台是个大工程做完之前你什么收益都没有。我的建议是先做三件小事每件都能在一周内看到效果。第一件环境巡检。磁盘、内存、进程数、证书有效期、备份是否成功这些东西每天看一遍和每周看一遍出事概率完全不同。巡检脚本的好处是它不会忘而人会。第二件发布回滚。这是收益最高的一块。发布流程如果还靠人手敲命令回滚就永远慢半拍而回滚速度直接决定了故障时长。把发布和回滚做成一条命令是投入产出比最高的自动化。第三件日志收集与检索。不是为了好看是为了在故障现场能三秒内捞到关键日志。很多人排查慢不是不会分析是找日志花了二十分钟。这三件事做完你会发现一个变化你开始有余裕了。余裕是所有的起点没有余裕什么体系、什么转型都是空谈。3.2 一个批量巡检脚本的完整实现我把巡检脚本的骨架贴一下它是纯 Shell 加一点点逻辑没有依赖任何平台扔到任何一台 Linux 机器上都能跑。之所以不用更高级的方案是因为这个脚本要在几百台机器上分发依赖越少越好维护。#!/bin/bash # 用途主机基础巡检输出结构化结果供后续汇总 # 设计原则单机可独立运行失败不中断输出机器可读 HOST$(hostname -s) REPORT/var/tmp/inspect_${HOST}_$(date %Y%m%d).log WARN0 log() { echo [$(date %F %T)] $* $REPORT; } # 1. 磁盘根分区使用率超过 80% 告警 ROOT_USED$(df -P / | awk NR2 {gsub(%,,$5); print $5}) log disk_root_used${ROOT_USED}% if [ $ROOT_USED -ge 80 ]; then log WARN disk_root_used high WARN$((WARN1)) fi # 2. 内存可用内存占比低于 10% 告警 MEM_AVAIL_PCT$(free | awk /Mem:/ {printf %d, $7/$2*100}) log mem_avail_pct${MEM_AVAIL_PCT}% if [ $MEM_AVAIL_PCT -lt 10 ]; then log WARN mem_avail_pct low WARN$((WARN1)) fi # 3. 关键进程存活检查进程名从清单文件读取 if [ -f /etc/inspect/process.list ]; then while read -r p; do [ -z $p ] continue if pgrep -x $p /dev/null; then log proc_${p}alive else log proc_${p}down log WARN proc_${p} not running WARN$((WARN1)) fi done /etc/inspect/process.list fi # 4. 证书有效期剩余不足 15 天告警 if [ -d /etc/ssl/private ]; then find /etc/ssl/private -name *.crt 2/dev/null | while read -r c; do END$(openssl x509 -enddate -noout -in $c 2/dev/null | cut -d -f2) [ -z $END ] continue DAYS$(( ( $(date -d $END %s) - $(date %s) ) / 86400 )) if [ $DAYS -lt 15 ]; then log WARN cert_expiring file$c days$DAYS fi done fi log warn_total${WARN} exit 0这个脚本有几个我反复权衡过的设计点。exit 0是故意的巡检脚本本身不能成为故障源某台机器上某个检查报错不应该让整批任务失败输出格式选成keyvalue是为了后面用grep或awk直接汇总不用写解析器告警项统一带WARN前缀汇总时一行grep -c WARN就能统计异常机器数。分发这一步用最朴素的批量执行就行比如# 假设主机清单在 inventory 文件里每行一个主机名 while read -r h; do scp -q inspect.sh ops${h}:/var/tmp/ \ ssh -o ConnectTimeout5 ops${h} bash /var/tmp/inspect.sh done inventory wait # 汇总捞出所有含告警的行按主机分组 grep -h WARN /var/tmp/inspect_*.log | sort | uniq -c | sort -rn并发执行那个加wait的写法很土但很好用。几百台机器几分钟跑完比一台一台串行快得多。ConnectTimeout5是必须的不加的话一台失联机器能把整个批次拖到天亮。3.3 配置管理的坑别让自动化变成批量事故自动化最大的风险不是脚本写不对是脚本写得太对——它会在几百台机器上同时、准确地执行你的错误。我第一次用批量工具改配置漏了一个引号十分钟内让二十多台机器的服务全挂。那次之后我给自己定了三条铁律。铁律一任何批量操作先在单台上跑通。单台跑通的标准不是“没报错”是“业务功能验证通过”。配置类改动尤其如此语法正确和业务可用是两回事。铁律二批量范围默认从一台开始逐级放大。一台、五台、百分之十、全量每一级都要看指标。这个节奏会让人觉得慢但它把事故半径控制住了。铁律三所有变更必须有回滚路径而且回滚路径要验证过。没验证过的回滚方案约等于没有方案。我现在的习惯是做变更之前先演练一遍回滚哪怕它看起来很明显。还有一个容易被忽略的点配置项的最终真相到底在哪。如果一部分配置在仓库里一部分在机器上手工改过那你所有的自动化都是建立在流沙上的。我见过最离谱的情况是同一台机器上有三份不同的配置服务到底读哪一份没人说得清。这种时候先别急着建平台先把配置收敛到唯一来源这一步不做后面全是白干。4. 故障现场把“背锅”变成“定位到系统”4.1 故障分级和响应动作故障处理最怕两件事一上来就全员扑上去结果十个人互相问“现在什么情况”或者所有人都觉得“应该没事”等发现的时候已经过去四十分钟。解法是提前定好分级和对应动作事发时只判断级别不讨论流程。级别判定标准响应动作目标恢复时间P0核心链路完全不可用或数据出现错误立即拉应急群主岗止损同步通知业务方30 分钟内恢复或降级P1核心链路部分受损或有明显性能劣化主岗处理备岗待命十五分钟一同步1 小时内恢复P2非核心功能异常有可用替代路径工作时间处理进当日工单24 小时内P3无业务影响仅指标异常进周会讨论不单独响应一周内这张表的作用不是让你照本宣科是让凌晨三点被叫醒的人能在三十秒内做出判断而不是花二十分钟讨论这算不算大事。判断标准里我最看重“数据出现错误”这一条因为它比服务不可用更隐蔽也更严重很多时候系统看起来好好的只是悄悄算错了数这种问题必须单列。处理过程中有个小技巧我用了很多年先止损再定位。大部分人的本能是先搞清楚原因再动手这在故障现场是错的。原因是定位可能需要一小时而止损可能只需要一分钟。先回滚、先切流、先降级把业务恢复过来然后你有大把时间从容分析。我见过太多因为急着找根因硬扛了四十分钟才回滚的案例最后根因也确实找到了但业务损失已经造成。4.2 复盘模板对着系统别对着人复盘这件事做得好是团队最值钱的资产做得不好就是公开处刑做完之后所有人都学会了下一次怎么把话说圆。我坚持的原则是复盘的对象是系统和流程不是某个人。模板我固定成五块写下来不超过一页时间线从第一个异常信号到完全恢复每五分钟记一笔。这条最有价值因为人的记忆会自我美化时间线不会。影响面影响了哪些业务、多少请求、多长时间。要具体到数字不能写“部分用户”。直接原因和根本原因直接原因是“什么坏了”根本原因是“为什么它能坏”。比如直接原因是连接池被打满根本原因是某个查询没有超时控制。临时措施和长期措施临时措施要写清楚什么时候撤长期措施要有负责人和时间点。没有负责人的措施等于没有措施。检测和响应环节的问题这一点经常被跳过但它往往比技术原因更值得改。比如“为什么监控没报”“为什么报了没人看”“为什么看了判断错了”。第四条里“临时措施什么时候撤”是我加的因为我吃过大亏。有一次为了止损临时调大了一个超时时间事情过去了没人管三个月后这个临时值成了新的隐患还顺带掩盖了一个慢查询问题。提示复盘会上有个简单的话术技巧把“你为什么没发现”换成“我们的监控为什么没覆盖到”。同样的意思一个指向人一个指向系统聊出来的东西完全不一样。4.3 容量和预案给自己留后路运维干久了会有一个体会绝大部分严重故障本质都是容量问题只不过表现形态各不相同。连接池打满是容量磁盘写满是容量线程队列堆积也是容量。所以容量这件事值得当成日常功课而不是等到告警了再处理。我的做法是给每个核心服务记三个数日常水位、峰值水位、扩容阈值。日常水位是平峰期的资源占用峰值水位是大促或者批量任务时的最高点扩容阈值定在峰值水位的百分之七十左右。三个数一摆什么时候该扩扩多少心里就有数了。扩容不是万能的有些地方加了机器反而不行比如锁竞争、单点写库、串行依赖。这类地方只能靠预案。预案我一般会准备三个档次降级预案关掉非核心功能保住主链路。比如临时关掉推荐、关掉历史查询。限流预案给入口设一个最大并发宁可拒绝一部分请求也不让整个系统雪崩。切换预案切到备用链路或者只读模式。这三档要提前写好开关而且开关必须能在一分钟内生效。写在文档里但需要改代码才能生效的预案等于没有预案。5. 技能栈和转型运维人的几条出口5.1 一张能自查的技能地图我把运维相关的技能分成四层从下往上。你可以拿这张表勾一下看看自己缺的是哪一块。缺底层就去补底层缺上层就去补上层别一上来就追新概念。层级核心能力常见抓手判断标准系统层操作系统、网络、存储、进程模型排查 CPU、内存、IO、连接异常给你一台陌生的机器能独立定位性能瓶颈服务层中间件、数据库、容器运行时部署、调参、备份恢复能说清一个请求从入口到落库经过了哪些环节工程层脚本、配置管理、持续集成、可观测性自动化发布、监控体系、日志体系能不靠人肉完成一次完整发布和回滚架构层容量规划、高可用设计、成本控制稳定性指标、故障演练、资源评估能用数字说明系统当前的风险点在哪这张表的用法是“往下扎”和“往右走”结合。系统层是地基它决定了你排查问题的上限架构层是天花板它决定了你在团队里的话语权。中间两层是最容易卡住的因为日常杂事全堆在这里。5.2 四条转型路径的真实差异这几年身边同事走出去了不少路子大概有四种。我把观察到的实际感受写下来不做优劣判断因为适配度比“哪个更好”重要得多。方向做的事情适合什么人门槛与代价稳定性工程方向定义指标、做容量、做演练、推动治理喜欢和数据、流程打交道能推动别人需要较强的沟通和推动力短期很难看到成果平台工程方向把运维能力做成产品给别人用喜欢写代码愿意打磨工具需要补工程能力编程底子差会很吃力专项深挖方向数据库、网络、性能调优等垂直领域专注度高能忍受长时间啃一个方向学习曲线陡且在小团队容易被当工具人技术管理方向带人、定优先级、对外沟通能扛压擅长拆解和分配会离技术越来越远心理落差需要适应我自己的选择偏平台工程和稳定性工程之间。选这条路的理由很实际我写代码不算特别强但比大部分人愿意写我喜欢把重复的事变成工具因为那能让我少加几次班。这个理由一点都不高大上但它真实而且它让我愿意在这个方向上持续投入。关于转型我特别想说的是别把转型理解成“换个岗位从零开始”。运维积累的东西里排查思路、系统视角、对故障的敏感度这三样在任何技术岗位都值钱。真正要补的是表达能力——你能不能把一次故障讲清楚能不能把一套方案写明白能不能用业务听得懂的话说明白为什么要投这笔资源。这个能力比多学一门语言重要得多。5.3 时间从哪来给学习排个可行的节奏“没时间学习”是所有运维人的共同困境我也不例外。后来我换了个思路不追求“每天学两小时”而是把这几个动作嵌进工作本身。动作一每次排查完写一段记录。不求完整写清楚现象、判断过程、最后怎么解决的就行。三个月下来你就有了一本自己的故障手册而且是带着思考过程的那种。动作二每次重复操作抽二十分钟写个脚本。哪怕只写了一半下次再遇到就能接着写。我现在手上那些工具一半是这么攒出来的。动作三每周抽一小时看一个已有系统。不看教程就看自己手里的系统挑一个模块问自己“它为什么这么设计”。这个动作的效果比刷视频课好得多因为它是贴着真实场景的。动作四给自己设一个可交付的小目标。比如“这个季度把发布流程自动化跑通”比“这个季度学好容器”具体得多也容易坚持。心得别把学习计划和加班混在一起。加班的时候学不进去学的时候想着工单没关两头都干不好。我现在是固定周三晚上不碰工单就用来写点东西或者看系统这个边界感很关键。6. 常见问题速查和踩坑实录6.1 高频问题排查表把常见问题和最容易走偏的判断列一下。这张表的用法是出事的时候先扫一眼别急着往下钻。现象容易误判的方向优先检查的位置服务响应变慢但 CPU 不高以为是网络问题连接池占用、下游 RT、线程阻塞、GC 停顿间歇性超时复现困难以为是偶发采集窗口是否太短、是否有定时任务、是否有连接重建磁盘突然写满以为是大文件先看被删除但仍被占用的文件、再看日志轮转是否失效机器内存持续上涨以为是业务量增长缓存是否无上限、连接是否未释放、文件句柄是否泄漏发布后问题消失以为修好了可能是重启掩盖了问题重点看是否有状态未清理告警忽多忽少以为是系统不稳先看告警规则本身是否有抖动再看采集是否丢点表里第五行是我特别想强调的。“重启一下就好了”这句话在运维圈流传甚广它的危险之处在于它总能生效于是很多人把它当成了解决方案而不是临时手段。重启确实能让症状消失但状态没清干净问题还会回来而且下次回来往往更严重。6.2 几个我实打实踩过的坑坑一把监控当成万能答案。有段时间我以为监控覆盖度上去了问题自然就少了。实际是监控只能告诉你“哪里不对”不能告诉你“为什么不对”。指标体系建得再全没有配套的排查路径现场还是一片混乱。后来我在每条关键告警后面都补了一行“下一步动作”情况才好转。坑二文档写完就不再看。我曾经很认真地写过一套运维手册写了六十多页结果半年后自己都不信里面的内容了因为环境变了三轮。现在的做法是把文档拆成小块每块标注最后验证时间超过三个月没验证的自动降级为“待确认”。文档的价值不在于长在于准。坑三只做加法不做减法。新工具、新流程、新报表一直在加。加到后来团队每天要填三个表、看两个平台真正干活的时间被挤没了。后来我们定了一条规矩任何新流程上线必须说明它能替代掉哪个旧流程。不能替代的就先不上。坑四把“我扛得住”当成能力。这是最隐蔽的坑。能连轴转、能半夜爬起来、能一个人扛三个人的活这些确实说明你能力强但它们不该成为常态更不该成为评价标准。一个健康的运维体系标志是“少了谁都能转”而不是“少了谁都不行”。我花了挺长时间才想明白这件事。坑五不敢说不。需求方说“这个改一下很快吧”你说“行”业务方说“今晚发个版”你说“没问题”。边界一旦失守后面全是默认。我现在会明确给出时间窗口和影响范围比如“这个改动今晚可以做但需要两小时窗口期间只读”。说清楚比答应得快重要。6.3 几个能立刻用上的小技巧最后放几个不需要任何预算、当天就能试的小动作。给所有批量脚本加一个--dry-run开关默认只打印不执行。这个习惯救过我至少三次。所有变更记录里加一列“回滚方式”哪怕写的是“重新部署上一版本”也要写。值班文档第一行永远写“当前系统状态”用三个词正常、降级、异常。交接的人第一眼就看到。给每个核心服务准备一条“一分钟自检命令”出问题时先跑它比翻文档快。复盘记录单独建个目录按季度归档。年底翻一遍你会发现重复问题集中在两三个地方那才是真正该投入的地方。跑路这件事我现在理解得比较清楚了。真正该跑的不是这个行业是那种“靠个人硬扛”的工作方式。我把值班表定清楚、告警砍干净、脚本写好、复盘做实日子就慢慢回来了。这个过程不快我花了差不多两年才看到明显变化但它是可积累的——今天写的脚本明天还在用今天定的流程下个月还在跑。这大概就是我对“不归路”这三个字最后的态度路是自己走出来的走成什么样多半取决于你愿不愿意在忙的时候还挤出二十分钟把刚才那件事变成以后不用再做的事。