IFTech BE Weekly #4

2020/10/23 10:17

关于最近搭建后端报警系统的一些总结

xingpeng Oct 15th at 18:02
@channel
当前我们基于 promethues 的报警体系正在搭建,有些问题想跟大家一起讨论下:
对于报警来说,有几个比较重要的点:

  • 第一是报警维度:不能什么都报,因为数量太多会淹没掉关键信息,而且会麻痹接收报警的人;也不能报的太少,不然不能及时的反馈问题。所以我们尽量做 critical 的报警,这个可以后续慢慢优化。
  • 第二是报警处理流程:流程还是比较重要的,不然就会很混乱,我这里列举几点:
    • 一个报警应该发到哪里?由 SRE 接收?但 SRE 实际上还是会人肉将它路由到各项目;按项目接收?就需要能够在逻辑上对报警信息做划分,然后发到各项目组独立的 slack channel,建议这种方式,因为正好可以利用 k8s namespace 的能力,也意味着各项目要按照一定的规范将服务部署到各自项目组对应的 namespace,方便在配置路由规则的时候设置统一的正则去匹配。
    • 收到一个报警由谁来处理?一个报警大家都看到了,A 以为 B 会处理,B 以为 C 会处理,结果大家都没处理,所以就需要一个机制来对报警做 ack。建议是值班人制度,每个项目组每天或者每周换值班人,由值班人驱动报警解决。
    • 怎么标记一个报警正在被某个人处理?当前临时的方式是我们这边通过 slackbot 做了一个功能,当值班人在 slack 上收到报警后,点击 Claim 按钮,slackbot 会自动会开启一个 thread 并在里面回复报警由该用户认领,值班人即可在该 thread 中处理该报警。如下图:
    • 如何保证报警暴露的问题已被解决或者在项目内部和所有人都同步过?建议可能是值班人制度对报警做一个总结并向同组所有人同步。
      以上是我们当前的一些想法,初步打算是按照这样去构建流程,欢迎补充和讨论。

以上是我们当前的一些想法,初步打算是按照这样去构建流程,欢迎补充和讨论

zengxian 7 days ago
补充一个目前这个提案的TLDR;下午可以线下讨论:
报警接收方式:按k8s namespace前缀划分各个业务的报警分组,每个分组有一个slack channel,该相关同事需要加入这个channel
值班制度:业务组同事轮流在channel里值班,负责跟踪每个故障,指派给相关同事解决,值班人要对每个报警的分配和关闭负责。其他同事发现业务问题的也可以人工发到channel

zengxian 3 days ago
这里讨论下值班制度和值班人责任:


themez commented 3 days ago
值班人责任:

- 按业务和infra划分值班人,初期先对即刻项目和infra采用轮班,其他业务松散自由安排
- 值班人值守期间必须打开相关故障群/channel的通知
- 值班人不一定直接处理故障,最重要的责任是接收和追踪故障的生命周期,需要at出解决问题的人,必要时电话联系,在故障反馈源头同步接收/处理中/已解决状态
- 其他同事无论事情大小可以随时打扰值班人
- 在故障群收到报警并确认后立即转移到其他群讨论,保证故障群敏感性

值班人工作流程:

- 在开始值班前打开#alert-业务channel和微信故障群的通知,平时留意下各个群/channel反馈的问题
- 发现监控报警/同事反馈故障,先claim
- 如果找到故障owner,确保通知他开始处理,并在相关的群里告知其他同事已经在处理了
  - 如果是不合理的报警,记录下来,告知 @xingpeng 调整报警规则
  - 对于在跟踪的故障,定时和故障owner同步处理进度,如果得到修复,在相关群/channel告知关心的同事。如果暂时无法修复,记录下来,方便后续值班同事查阅了解情况。
- 在结束值班周期后,整理值班总结,记录前面提到的误报,暂时未解决等问题,发布到ph上,通知下一个值班的同事开始新的值班周期

stanxing commented 2 days ago
我想补充一点关于报警处理原则的观点:

值班报警处理原则:

每个报警报出来肯定是需要处理的,如果某个报警报出来了,分析完之后发现不需要处理,请反馈,应该想办法绕过这个报警或者删掉(禁掉)这个报警。
遇到任何觉得不合理或欠缺的报警规则请反馈。
总结这一周(一天)的报警,比如有多少是重复问题导致的,比较难修复的问题,应该有相应的 issue 记录,不然问题就会越积越多,下个值班的人仍然会遇到。
报警优先级的定义这块当前定义的比较随意,只有 warning 和 critical,长远看不太合理,后续我在考虑用 p0 p1 p2 p3 这样的代替,按 namespace(beta,prod) + 业务(重要性)两个维度做优先级,但是不管怎样,我觉得报出来就是应该要处理的,不然就没必要报,应该选择删掉它。

一些产品分享

WangSiyuan Yesterday at 15:22
https://miro.com/
看到Medium在用这个网站,做在线协作。特点应该是实时/异步协作,有一个无限白板,也可以和非常多的网站集成,同时有视频分享。
image.png

大核桃 1 day ago
还有个类似产品是:https://www.mural.co/
大核桃 1 day ago
不过我觉得这类产品是figma捎带手就能做出来的,依托于性能强大的画布和协作功能

xidong 1 day ago
做得非常好啊

最近流行去苹果化,有同事尝试在换用windows作为主力开发本

WangSiyuan 10:55
有什么好用的windows软件和开发经验

WangSiyuan 10:57
listary不错 https://www.listary.com/ (edited)

formula 10:58
tuneblade不错 http://www.tuneblade.com/
可以在Windows上连HomePod

WangSiyuan 10:58
https://github.com/Awesome-Windows/Awesome

panqianyu 10:58
powerToys 不错,可以勉强替代 karabiner
https://github.com/microsoft/PowerToys (edited)

Renzh 11:22
https://jmeubank.github.io/tdm-gcc/

呆唯 11:58
现在Win本真的白菜价

Renzh 14:08
http://www.lingoes.cn/
Lingoes 灵格斯词霸 是一款简明易用的词典与文本翻译软件,支持全球超过80多种语言的词典查询、全文翻译、屏幕取词、划词翻译、例句搜索、网络释义和真人语音朗读功能。同时还提供海量词库免费下载,专业词典、百科全书、例句搜索和网络释义一应俱全,是新一代的词典与文本翻译专家。 (edited)
以前学新东方的时候,老师推荐的

WangSiyuan 14:12
@Renzh 你的类似alfred的是什么app呀?

Renzh 14:13
PowerToys
只用于启动,不干别的

zhangxuhui 14:14
https://u.tools/

panqianyu 14:23
感觉Windows上的终端还是hyper比较好,比ms自家的好

大核桃 14:42
https://getquicker.net/
还可以,就是UI丑

WangSiyuan 14:45
想到这个了:https://www.autohotkey.com/
非常好用

大核桃 14:46
还有经典的Everything

WangSiyuan 14:54
LinusTechTips的剪辑师的AutoHotKey脚本repo:
https://github.com/TaranVH/2nd-keyboard
他常用的script
https://www.youtube.com/watch?v=OqyQABySV8k

WangSiyuan 17:14
问一下,不同的windows之间有什么文件同步的好方案吗?不用网盘,在公网 (edited)

panqianyu 17:19
resilio sync

WangSiyuan 17:28
这个不错
https://github.com/c0re100/qBittorrent-Enhanced-Edition
可以订阅tracker列表 (edited)

Node.js v15.0.0 released

https://nodejs.medium.com/node-js-v15-0-0-is-here-deb00750f278

  • AbortController
  • N-API Version 7
  • npm 7
  • Throw on unhandled rejections
  • QUIC (experimental)
  • V8 8.6

这周有什么好笑的

haha.png