CMS 迁移属于少数几类项目：技术活可以做得毫无差错，结果却仍然是一场灾难。站点按期上线，样子更好看，加载也更快，流量却掉了一半，原因是几百条网址换了形状，而没有人去做那张对照表。技术验收一项项全过，商业结果却是负的。 丢掉的流量并不是新平台造成的，而是断裂造成的：以前能响应的地址现在不再响应，以前能被认出来的页面现在看起来像全新的，多年积累在旧网址上的历史也失去了去处。而且排名往往不是上线当天就掉下去，而是在随后的几周里慢慢往下沉，所以上线当天看着一切正常，并不能说明任何问题。 决定结果的只有一个判断：你要保留 URL 结构吗？ 如果保留，迁移基本上就是一件内容和模板的活儿，风险有限。如果不保留，每一条变动过的地址都需要一条指向其...
文章
在一个页面浏览所有文章。查找关于人工智能、编程、安全、基础设施与 Web 开发的教程、深度解读、指南与更新。
故障复盘很容易开起来，很难做得有用。会开了，文档写了，四条改进项记下来了，六个月后同一个故障又发生一次，而某个人正好在找别的东西时翻出了那份旧文档。 在讨论这件事时，注意力几乎都落在"无指责"这个词上。这条原则确实重要，但失效的地方并不在那里。有大量组织把无指责执行得一丝不苟，复盘却什么也没有改变，原因很简单：他们把复盘本身当成了交付物，而不是当成产出交付物的手段。 判断你们的复盘是否有效，有一个简单到让人难堪的测试：过去六个月记录下来的改进项，实际完成的比例是多少？ 如果答案是"大部分"，那么无论流程长什么样，它都在起作用。如果低于一半，你们是在开会而不是在运行一个流程，换更漂亮的模板也救不了。少数几条带负责人和期限的事项，胜过一...
密码存储是软件里少数几个真正存在标准答案的领域之一。答案早就公开了，一直有人维护，而且免费。可它同时又是最经常被做错的领域之一，原因很简单：那些错误的做法在某个年代确实是正确的，而后来没有人再回头看过一眼。 失败的样子很少稀奇。通常就是一套 2016 年按照 2012 年的建议搭起来的系统，到今天还在跑，还在接受登录请求，而自从当初写下那段哈希代码的人离职之后，就再也没有人打开过那个函数。它没出过故障，也没被审计过，所以从来不在任何人的待办清单上。 如果只带走一句话：用 Argon2id，实在不行就用 bcrypt。 本文其余部分都是细节。像 SHA-256 这样的通用哈希函数，无论你把它套用多少次，都不是密码哈希。它的快是设计目...
软件供应链安全听上去像是那些设有专职安全团队的大机构才需要操心的事，而正是这种定位把人带偏了。一个只维护少数几个服务的小团队，通常也依赖着几百个包，其中没有一个是团队里有人真正读过的。这些包在构建时从团队并不掌控的包仓库里拉取，然后在存放着部署凭据的机器上执行安装脚本。 暴露面并不随公司规模等比增长。它随依赖数量和构建自动化程度增长，而小团队往往前者更多、后者更少有人盯着，处境比那些公开讨论这件事的大机构还要吃紧一些。 令人不适的算术： 你的应用大概有十几个直接依赖，以及几百个间接依赖。这十几个是你自己挑的。剩下的不是，你一个都没读过，而其中任何一个只要执行安装脚本，拿到的权限就和你的构建进程完全一样。这才是真实的攻击面，而在你亲手...
多语言 SEO 通常被讲成一个翻译问题，外加一点技术标记。但把这个站点用十二种语言运营下来，也就是英语、阿拉伯语、德语、法语、匈牙利语、意大利语、日语、韩语、罗马尼亚语、越南语，加上中文的两种书写形式，我们很清楚地看到：翻译才是简单的那一半。 难的那一半在于，你在英语里习以为常的每一条规则，都有一个依文字系统而变的版本，而你原本并不知道它存在。长度上限不一样。结构会跑偏。数字会被一个想帮忙的译者写成汉字，从那一刻起就不再和原文对得上。这些问题在有东西去检查之前，一律看不见。 真正让它跑起来的是自动化，不是努力。 在任何内容上线之前，有十一项独立检查会从头到尾扫一遍：语言覆盖率、原文与各译文之间的结构一致、数字一致性、标题层级顺序、死...
在多数已经运营了一段时间的网站上，内容更新是回报率最高的一项工作，而它之所以不受欢迎，正是因为做完之后没有任何东西可以拿出来宣布。修改一篇已经有排名的文章，感觉像是在做维护。发布一篇新文章，感觉像是在往前走。数字通常不同意这种感觉。 原因在于，一个已经存在的页面早就积累了那些昂贵的东西：外部链接、抓取历史，以及与一组搜索词之间被验证过的关系。新页面从零开始，什么都没有，要花上好几个月才能挣到旧页面早已拥有的东西。而改进旧页面，是直接叠加在这份积累之上。 会让整件事白做的错误，是只改日期，别的什么都不改。 这种做法足够常见，值得把话讲明白。一个把新鲜度纳入考虑的检索系统，比较的是内容而不是时间戳，一个日期动了、实质却原封不动的页面，除...
程序化 SEO 指的是用一套模板加一份数据集批量生成页面：每个城市一页、每个产品组合一页、每种参数组合一页。如果用的是真实的数据集，它是这个行业里效率最高的做法之一。如果用的是同义词词典和洗稿工具，它就正是搜索引擎花了二十年学着识别的东西。 区别不在技术。两条路都会大批量地产出模板页面。区别在于每一页是否包含只有这一页才能回答的东西，而这是关于你手里数据的问题，不是关于你内容流程的问题。换句话说，这个问题的答案在数据库里，不在编辑部里。 区分两者的检验方法： 把模板拿掉，看看一页上还剩下什么。如果剩下的是真正不同的事实、不同的价格、不同的数据集、不同的计算，这一页就有存在的理由。如果剩下的是同一段文字换了个地名，...
技术文档的失败方式非常具体，也非常好预测。有人在两周清闲的时间里写下一大堆，接着系统变了，没有人回头更新，一年之内那份文档就开始信心十足地讲着错误的内容。到了那个时候，它比什么都没有还要糟，因为相信它的读者会依据早已不成立的信息去动手。 常见的反应是号召大家多写一些，而这只会让同样的失败来得更快。有用的反应是少写，并且认真挑选写什么，因为真正的瓶颈不是写作的工夫，而是维护的工夫。文档从写完那一刻起，就开始被现实甩在后面。 判断一份文档该不该存在，唯一经得起时间的检验是： 当它变错的时候，会不会有人察觉？部署指南天天有人用，错误立刻就会浮出来。一份二十页的子系统说明只会被读一次，它的错误要等到十八个月后，有人照着它动手时才浮出来。没有...
开发者入职通常是按入职培训花了几天来衡量的，而那是问题的另一头。真正重要的数字是另一个：一个新来的工程师要过多久，才能改动某个东西，并且有把握自己没有弄坏别的地方。在大多数团队里，这个数字是以月计的，而不是以天计的。 延迟很少出在人身上。它出在系统里有多少部分只存在于别人的脑子里，以及前两周里有多大一部分时间，是靠一次次打断别人，一点一点把这些东西挖出来的。 唯一值得追踪的指标：从入职到他们的第一次改动进入生产环境，需要多久。 不是第一次提交，提交可以只是改一个错别字，而是一次有意义并且真正上线的改动。如果这个时间超过一周，障碍几乎从来都不是能力。而是一份最近没有人从零走过一遍的环境搭建流程，或者一份没有人带路就找不到入口的代码库。...
可用性 SLA 看上去像一句承诺，实际运作起来却更像一份退款政策。供应商很清楚这一点。客户往往并不清楚，于是在签署服务级别协议时以为自己买到了可用性，而真正买到的，只是万一没拿到时的一点折扣。 这不一定是笔糟糕的交易。它只是与大多数人以为自己在签的那笔交易不同，而这个差别恰恰在系统宕机、有人追问合同究竟怎么写的那一刻显现出来。 三个九听上去接近完美，却允许每月 43 分钟的停机。 四个九允许四分钟。如果你的业务能吸收工作日下午 43 分钟的中断，99.9% 就足够了，不必为更高的数字付费。如果吸收不了，再多的九也帮不上忙，因为协议给你的是一笔积分，而不是阻止这次中断。 可用性 SLA 用分钟兑现的承诺百分比把一个非常大的区间压缩成看...