讲故事与叙事2017news.ycombinator.com
说说你职业生涯中的工程“战争故事”
Ask HN: Tell me an engineering war story from your career
导读
这是 Hacker News 上一个征集「工程界战争故事」的帖子，几位工程师用第一人称讲述了自己亲历的真实事故：接错电源烧掉两百台服务器、整点拨号压垮基站、直接在生产环境改代码、投影仪被开门的气流触发关机。对写作者的价值在于，这些故事示范了如何用具体细节、清晰因果链和克制的短句节奏，把技术事件写成有画面感、可信又好看的叙事。
可以直接用的写作要点
- 01
用可感知的细节代替形容词：不写「很危险」，而写「像一条龙喷出绿色的火」「我抓起椅子，以防他被电吸住」。
- 02
先把因果链交代清楚再给结果：「整点拨号、没有随机延迟、GPS 授时极准」这几句铺垫，让「基站崩溃」这个结果显得可信而非夸张。
- 03
开头给读者时间和场景锚点（2003 年、印度创业公司、卡车追踪系统），读者才愿意跟着往下走。
- 04
结尾用一句冷静的收束或反差（「我因在紧急情况下保持冷静受到表扬」「他们没有骂人……」），比直接抒情更有余味。
HN 评论精选
用短句、感官细节和人物动作把事故写成有节奏的现场，最后用一句冷静的评价收束。
我们刚收到 IBM 的新主机，我的任务是当里面 LPAR/Linux 实例的系统管理员。电源接头得「改装」成当地标准——你让本地承包商读英文手册，然后祈祷一切顺利。那天数据中心只有我和 IBM 技术代表两个人。我在检查刀片服务器时，看到他在离我五米处插上电。只听一声巨响，我第一次见到电火，像一条龙喷出绿色的火。我大喊让他停下、走开，他本能地拔了插头（我抓起一把椅子，以防他被电吸住时砸过去）。停了，然后一切漆黑。灯亮了，他看着我，我往身后一看——两百台服务器全部宕机，连 APS 系统都被搞坏。我走到分机前拨 28 给同事：「P……过来。很严重！把所有人都叫来……大问题……超——大。」我们得按正确顺序重启一切（SAN 存储、AD、服务器、SQL），但我们知道该怎么做。八分钟后电力公司的人到了，那位 IBM 技术员因压力导致心脏骤停被送进医院。他运气好，活下来了。而我因为「在紧急情况下保持冷静」得到了好评。
superflit查看英文原文
Well, this is a different war story. We just received a new Mainframe from IBM. Big beast big power consumption. My primary task was to be Sysadmin of LPAR/instances of Linux inside the new IBM. The new mainframe was unpacked, and the power connectors had to be "modified" to the local standard. You know.. You ask your local contractor to read the manual in English and hope for the best. There was two person on that day on that Data Center. Me and the IBM Tech Representative. Well, I was checking some blade servers looking at the Robotic library, and I see him plugin it 5 meters from me. I just heard a BANG. And for the first time, I saw an electric fire. Like a Dragon spitting green fire. I shout for him stop and move away. He by instinct unplugged it (I grabbed a chair to throw at him if by chance he gets stuck on electricity). It stops. And everything gets pitch black. Lights on He looks at me. I look behind. And there are. 200 servers Down. all Down. It even had broken the APS system. I walk to the extension. Dial 28 to my co-worker and say: "P.... come here. Serious! Get everybody here... Big problem.. BiiiiiiiiiiiiiG." We had to start everything on its right orders (SAN storage, ADs, Servers, SQL) but we knew it. 8 minutes late the electricity company appears the IBM tech had to go to the hospital with cardiac arrest by the stress. The IBM tech guy got lucky and is alive. I got a good recommendation for keeping cool in emergency situations.
一个看似无害的技术决定（整点同时拨号）引出连锁灾难，因果链讲得干净，还顺带交代了当地文化背景。
2003 年我在印度一家创业公司做 GPS/GSM 车队卡车追踪。设备用 GPS 定位，再通过 GSM 短信把位置发到我们服务器。那时信号覆盖差，卡车可能几天在盲区；更麻烦的是固件会崩溃，设备就停止上报。为了排查，老板让我编程让设备每小时给服务器打一个「未接来电」——在印度，未接来电是零成本的沟通方式，就像你开到朋友楼下给他一个未接来电，表示你在外面等。我实现了这个逻辑，派技术员去高速上拦卡车刷固件。我的写法是：设备每小时整点拨我们服务器的调制解调器号码，没有随机延迟。于是很快约 50 台设备同时拨号。设备时钟靠 GPS 对时，超级准。这直接把电信公司的基站打崩了，我办公室所在的班加罗尔繁忙地段手机信号断了整整两小时。我被叫到电信公司总部参加他们的复盘会。他们没有骂人……
msound查看英文原文
In 2003, I was working for a startup in India doing GPS/GSM based vehicle tracking system for fleets of trucks. The trucks would have our unit installed in them, and they would use GPS to get the location and send it to our server via GSM text message. Back then, GSM coverage not good, and trucks would go out of coverage for days. To further complicate matters, our firmware used to crash and the unit would stop sending updates. To help us troubleshoot this, my boss asked me to program the unit to give a missed call to the server every hour. If we got a missed call, we knew that unit was still working. In countries like India, giving a missed call is a zero cost way to communicate. For example: You would pull up in front of a friend's place and give them a "missed call" to let them know that you are waiting outside etc. Anyway, I implemented the logic and we sent off our field techs to intercept trucks at highways and update the firmware. The way I implemented the logic was the unit was to call our server's modem number every hour at the top of the hour. No random delay nothing. So, soon after that, around 50 units tried to call our server at the same time. Remember the clocks in the units are being run off GPS and they are super accurate. This caused our telecom company's cell tower BTS to crash. Cell service in my office area, a busy part of Bangalore, was down for a whole 2 hours. I was called into the telecom company's head office for their postmortem. They didn't yell at me or anything. They were super nice. In fact, when I finished explaining my side of the story, one of their engineers opened his wallet and gave a hundred rupees to another guy. Guess they were betting on the root cause. From what I understand, they escalated the bug to Ericsson who manufactured the BTS and got it fixed. For my part, I added a random delay and eventually removed that feature.
用「只有一个环境：生产环境」的反差和一串具体失误清单，把荒诞的管理写成黑色幽默。
这是我大学毕业后第一份真正的工作，在一家单人财富咨询公司做 VB script/网页开发兼职，老板想在 2001 年做网上慈善捐款的副业。他没耐心，懂一点 HTML/CSS 就危险地以为自己懂编程；又强迫症到看到不同浏览器渲染不完全一致，就让我把网站上所有文字都做成图片——因为图片在任何浏览器里看起来都一样。支付部分呢？因为他抠门，不想让我花时间做版本管理、部署、测试，我们只有一个开发/测试环境：生产环境。没错，我把 VisualStudio IDE 直接连到生产 IIS 服务器的文件系统上写代码，敲下保存那一刻代码就上线。因为我们没有监控、日志、分析这些「不必要」的东西，他永远看不出有多少笔实时交易是因为我忘了闭合某个标签、循环多跑一次、截断了卡号某几位、把名和姓弄反，或者误把支付网关对慈善机构设成「入账」而不是「扣款」而丢掉的……
canterburry查看英文原文
This was probably my first real job/contract out of college. I was a VB script/web developer and landed a part time gig at this one man wealth advisory firm who wanted to build a side business from processing charitable donation online (back in 2001). The owner was a very impatient youngish founder who new just enough about HTML/CSS to have the dangerous notion that he new something about programming. Additionally he was obsessive compulsive to the point where when he saw that different browsers didn't render the HTML/CSS EXACTLY identically in all cases, he had me redo ALL text on the site as IMAGES!..because those would look the same regardless of what the browser supported. Now, the payment processing part. Since he was a cheap bastard and didn't want me spending any time on actually versioning, managing code, doing deployments, testing etc....we only had one development/test environment: PRODUCTION. Yup, I'd connect my trusty VisualStudio IDE directly to the file system on the production IIS webserver and code away. Whatever I had coded when I hit save...was live. No issue. Since we had no monitoring, logs, analytics or anything else unnecessary like that, he never could tell how many live transactions were lost because I had forgotten to close some tag, looped once too many times, mistakenly truncated some part of a card number, swapped the first name and the last name field accidentally or mistakenly told the payment gateway to CREDIT rather than DEBIT the charity's account (yes, that one did happen...and he did notice). I would come home a nervous wreck every day just wondering what kind of pissed off customer calls I'd be hearing about the next day for something I had done that day.
先让故障重复出现制造悬念，再揭示「风」这个意外变量，用排除法把诊断过程讲成解谜。
给一家历史悠久的电影院做数字视频升级，全新 3D 投影仪比我的房子还贵。一切检查都很好，试映时运行完美。到了开幕夜，离放映还有半小时，有人打开控制室的门，投影仪突然关机——没有警告、没有提示音，就是崩溃式关机。重启后几分钟，开门时同样的事又发生。他们只好在开幕放映期间一直关着门，并尽快联系厂商。厂商翻查了超级机密的诊断日志，发现测试和开幕夜唯一的差别是：影院前门开着，那晚风很大。投影仪排气口里有一个「风向标」式气流传感器，用来反复确认风扇运转正常；控制室门一开，气流突变，足以让传感器读数下降、触发紧急关机。因为投影仪还有风扇和温度传感器，厂商批准我们旁路掉气流传感器。
jweather查看英文原文
Doing a digital video upgrade for a historic movie theater -- brand new 3D-capable projectors that cost more than my house. Everything's checked out great, the projector has run perfectly for test screenings. Fast forward to opening night, half an hour before showtime, somebody opens the door to the control room and the projector suddenly shuts off. No warnings, no chimes, just crash shutdown. They start it back up, and a few minutes later the same thing happens again when the door is opened. They managed to keep the door closed through the opening night showing, and got the manufacturer on the phone ASAP. Manufacturer goes through the super-secret diagnostic log files. Turns out that the only difference between testing and opening night was that the front doors of the theater were open, and it was a windy night. The projector has a "wind vane" style airflow sensor in its exhaust vent to check and double-check that the fans are running correctly. The sudden changes in airflow when the control room door was open was enough for the airflow sensor to drop and trigger a panic shutdown. Since the projector also had fan sensors and temperature sensors, the manufacturer okayed us to bypass the airflow sensor.
同类还值得读
Pixar in a Box：可汗学院的皮克斯讲故事课
Pixar in a Box – Khan Academy
这篇是 Khan Academy 与 Pixar 合作的“Pixar in a Box”项目介绍，用计算机图形和动画制作来讲解数学概念。
讲故事与叙事2015 · 753 分 · 65 评4 条写作要点编辑精选皮克斯的讲故事法则
Pixar's Rules of Storytelling (2013)
这是皮克斯动画工作室流传甚广的 22 条讲故事法则清单，从“从前有个___，每天___，有一天___”的骨架，到如何重写自己讨厌的作品。
讲故事与叙事2018 · 513 分 · 74 评4 条写作要点编辑精选皮克斯通过可汗学院提供免费在线讲故事课程
Pixar offers free online lessons in storytelling via Khan Academy
这篇报道介绍皮克斯与可汗学院合作的免费在线课程《讲故事的艺术》，把皮克斯内部的故事创作方法公开给普通学习者。
讲故事与叙事2017 · 503 分 · 93 评4 条写作要点编辑精选用皮克斯的故事公式说服投资人
Use Pixar's story formula to win over investors
这篇文章借用皮克斯的故事公式（以《海底总动员》为例）来示范如何给投资人讲创业路演故事：先讲目标、再讲障碍、最后讲改变。
讲故事与叙事2021 · 439 分 · 188 评4 条写作要点编辑精选贝索斯如何把叙事变成亚马逊的竞争优势
Jeff Bezos Turned Narrative into Amazon's Competitive Advantage
这篇讲杰夫·贝索斯如何把“六页叙事备忘录”变成亚马逊的管理与竞争优势：用可独立阅读的叙述性文档替代口头汇报和 PowerPoint。
讲故事与叙事2019 · 435 分 · 181 评4 条写作要点编辑精选