Skip to main content

Search: #ops

share
share

  1. #ops
    2025.9.2 Matrix.org 爆炸回顾

    Matrix.org 使用 pgsql 作为他们的数据库。整体架构是主从+推送WAL到S3。
    事情起因是数据库硬盘占用已经到了90%（51TiB），所以运维打算添加硬盘。
    1. 在机房添加硬盘的时候，主数据库 RAID 阵列里一个已有的硬盘消失了。阵列是RAID10模式所以整个服务器还只是降级。
    2. 这时运维打算把流量切到备用服务器上，然后修复主要服务器的阵列问题。调整主从角色之后运维决定重启降级服务器，希望RAID阵列能够自行恢复。
    3. 然而RAID阵列没能够自行恢复，直接炸掉所有数据。雪上加霜的是现在的主要服务器上面的WAL->S3脚本被发现有bug，WAL一直没能正确上传到S3。
    4. 此时运维团队决定重做整个服务器，并且把备份脚本修好。幸运的是这两者都成功了。这是他们打算开始从备份恢复一个完整实例，于是他们开始用 wal-g 工具来执行。
    /mnt/data/postgresql/ # wal-g xxxxx 2>&1 | tee restore.log 结果因为目录非空而失败。然后他们又切到 ~ 下执行，这次还是因为目录非空失败。
    5. 这次他们打算 # rm -rf /mnt/data/postgresql/ 了，然后喜闻乐见的是， 删错机器了 ，他们删到正在运行的服务器上了。他们马上发现了这个错误并且把数据目录remount成ro避免进一步破坏。
    6. Matrix实例服务中止（Matrix不应该是去中心化的吗.webp），运维团队决定抛弃现有数据库，开始从冷备份里面开始恢复数据库。然而巨大的数据量+WAL replay消耗了相当长的时间。可喜可贺的是，整个服务还是正常恢复了。

    Matrix.org 总结的教训
    1. 别把数据库搞得那么大。 Synapse（Matrix.org的实现）正在实现这一点。
    2. 增量备份弄的勤快一点，不至于有那么多 WAL Replay。
    3. 不要用 db-01 db-02 这种容易混淆的命名。
    4. 不同服务器终端的背景颜色要明显不一样。
    5. 用zfs做本地snapshot（在CoW上跑数据库吗？哈基米你这家伙。）

    编者评价：其实挺不错的了，至少没丢，而且主要的不可用时间是因为数据传输导致的。（

    https://www.youtube.com/watch?v=W42YJYkO8gw
    https://matrix.org/blog/2025/10/post-mortem/

  2. #ops
    1：运维误操作之后不可隐瞒，尽快通知其他运维人员，迅速恢复。误操作之后不要有侥幸心里，不要认为不会被发现，没人知道，从而避免自己被批评，隐瞒不报会给公司带来更多损失。
    2：禁止运行自己不理解的命令和未知脚本。尤其是在生产环境，不要运行自己不理解的命令，可能会闯祸。有人使用dd命令测试磁盘性能，却毁掉了生产数据，给公司带来数十万损失。
    3：生产环境禁止用于个人试验用途，禁止用来练习脚本技能等。保持学习和持续提高自身技能，是很赞的工作态度。但是请不要在生产环境进行练习，有闯祸风险。
    4：禁止运行来路不明的破解软件，优先选择开源软件或授权的商业软件。网络上随意下载的软件可能包括木马病毒和勒索软件等，如发生内网传播，对严重破坏公司数字资产，如勒索软件。
    5：禁止从数据库中导出用户数据后，未经脱敏步骤就发送给其他人员（运营，开发等）。从源头上保护用户数据安全，减少泄露风险。禁止出于好奇心和炫耀目的，将用户数据发放到社交平台。
    6：禁止变更方案中不包含回退方案，要有应对意外的准备。不怕一万，就怕万一，要为突发情况准备应急方案。
    7：禁止以任何方式变相压榨外包运维工程师。道德上来说，尊重他人。其二，公司运维负担临时增加时，外包工程师辅助完成公司任务，管理层应能力范围内为外包同学多争取福利。
    8：禁止大范围更新配置和数据前，没有进行小范围试点。灰度发布同样适用于运维，灰度发布过程中能提前发现问题，避免大范围影响到全局环境。小范围验证通过后，按批次更新剩余节点。
    9：禁止变更后不检查业务，信心十足地认为业务无问题而无需检查。变更前尽早检查是否满足变更前提，变更后验证业务是否正常。一次成功的变更包括了业务运行状态的检查。
    10：禁止将公司敏感文档，商业方案，产品关键架构和代码上传到外部网站换取积分等。可能给公司带来无法预测的后果，甚至引发公司倒闭。
    11：运维人员身体不舒服，状态不佳时，禁止做高风险变更。带病和状态不佳时，进行高风险工作是不建议的，高风险变更前要神智清晰，不可过量饮酒等。（编者注：就不要喝酒）


    作者：运维猫猫侠
    链接：https://zhuanlan.zhihu.com/p/822488366
    来源：知乎
    著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。