公司内部分享
公司20年老系统+传统组织, 正面临数位转型中
团队管理与开发定义SLO目标
DevOps这文化带给传统开发团队的新思维与习惯
纪录,监控与可观测性带给开发与维运双方团队的好处
主要针对公司内部现况做分享.
站在DevOps的右侧, 偏运维角度看事情
Observability的部分只是介绍
Note:
某天中午, 运维组内暴发出警报通知, 一堆讯息涌现. 大家也跳了起来, 发现网站瘫痪了, 外部监控近几次健康检查都没过, 而触发了警报.
Note:
发现网站瘫痪了
Note:
登入主机监控系统, 发现网站的系统指标正常, 记忆体也还有, CPU没到100%, Disk跟IO也还在容许范围内, 资料库也活着
Note:
不知道原因只好把问题扩大到开发团队, 因为主机与网站服务的进程本身看起来还算正常
Note:
开发团队也不确定要看什麽, 且它们没有直接登入正式环境主机的权限; 也不会让所有人都有权限进入主机, 管理成本高与资安风险高
Note:
开发团队只好与运维团队一起工作并且只能发号施令
最终在资料库上发现, 一堆慢查询跟一堆连线处於CLOSE_WAIT状态
在Web服务上也看到有几乎一样多数量的进程
推测很可能Web服务已经达到了最大处理容量并停止响应新的request(例如healthcheck)
最後把db的query session都砍掉, Web服务上的请求队列也清空, 就正常了
Note:
查找这些问题的根源, 浪费了很多时间;
当问题被升级时, 被波及的人也没足够权限查看对找问题有用的主机资讯与服务资讯.
最终还是得依赖运维团队.且在这种情境下, 每一分钟的无法服务或停机时间都是要钱的
运维团队之所以只能把问题扩大, 是因为他们能看到的就几乎只有主机的监控指标,
Note:
Developer与Operations如果组织结构与合作方式上职责分的太开, 往往会像拔河一般, 分散了力道.
相互拉扯中, 复原时间就流逝了.
Note:
最可怕的还是, 使用者对平台提供的服务品质没信心了, 跳去竞品平台了
Note:
Developer与Operations不应该相互拉扯在拔河, 而分散了众人的力道.
Note:
SLI(service level indicator)
指的是指标,例如:QPS,TPS,Duration,准确性,延迟,性能等
不是所有的metric都视为SLI,选择尽可能少的SLI,但这些SLI却能说明服务是否稳定,可靠。
SLO(service level objective):服务等级目标
指的是一段时间内的目标,例如:1个月内的QPS 99.99%,响应时间<10ms等等
SLO是一组值的范围,这个值就是由SLI定义的服务级别数值。自然的SLO定义就是,某SLI在正常情况下需要小於某值或者处於某个大小值之间。
选择一个合适的SLO并不是一件容易的事情,当然一开始并不需要设定好这个范围
SLA (service level agreement):服务等级协议
指的是整个协议,协议的内容包含了SLI,SLO以及恢复的方式和时间等等一系列所构成的协议
基於时间的可用性 = 系统正常运行时间 / (系统正常运行时间 + 停机时间)
SLO 99.95%, 以一年来看, 不可用占了4小时22分钟
SLO 99.99%, 以一年来看, 不可用占了52分钟
基於合计的可用性 = 成功请求数 / 请求数总和
SLO 99.99%, 如果一天要接受2.5M个请求, 每天错误个数应<250个
SLO 99% 前台每秒User访问延迟 < 300ms
Deal with discrete events
[INFO] .... initializing...
[INFO] ... request from xxx.xxx.xxx.xxx user_id xxxxxx
Note:
有价值的资讯密度太低, 很多都是第一行那样的无价值资讯
这部影片主要讲了很多
Log Cetralize and Monitor的好处
跟Log要怎清楚的表达
Logging in the age of Microservices and the Cloud
4 Golden Signals
Note:
反映用户体验,衡量系统核心性能。如:系统的处理时间,作业计算系统的作业完成时间等。
反映系统的服务量。如:请求数,发出和接收的网络封包大小等。
帮助发现和定位故障和问题。如:错误总量、调用服务失败率等。
反映系统的饱和度和负载。如:系统占用的内存、作业队列的长度等。
<metric name>{<label name>=<label value>, ...}
# TYPE http_requests_total counter
|--------------------------- Metric ----------------------------|-timestamp -|-value-|
|--- metric name --|------------------ labelsets ---------------|
http_requests_total{code="200",handler="prometheus",method="get"} 721
Note:
label sets代表了这个metric name下的一个维度,可以有多个维度方便做聚合操作
- Counters (rate)
- Gauges (value)
- Distribution
- Histogram (heatmap)
- Summary
Note:
counter只增不减, 通常用来取得request总量, 任务完成的数量, 错误发生次数, 或者计算某段时间内的rate变化率; 能事前透过压力与负载测试能取得可预期的上限, 做监控与警告;
查询当前系统中,访问量前10的HTTP URL.
gauge即时变化情况, 随着时间不断变化, 通常用来记录cpu, mem用量, coroutine数量, pool usage, 并发请求数...;
透过计算样本的线性回归模型, 对数据的变化趋势进行预测.
Histogram会对观测数据取样,然後将观测数据放入有数值上界的桶中,并记录各桶中数据的个数,所有数据的个数和数据数值总和, 请求时延, 各种有样本数据;用来区分是平均的慢还是长尾的慢,快速了解监控样本的分布情况
Summary 与 Histogram 类似,会对观测数据进行取样,得到数据的个数和总和。此外,还会取一个滑动窗口,计算窗口内样本数据的分位数。
Note:
Monitoring tells you whether system works, observability lets you ask why it's not working
【企业SRE实例:新加坡星展集团】顶尖数位银行如何再进化,SRE转型是变身科技公司的关键
【台湾SRE实例:17Live集团】多功能型SRE化身内部信心来源,天天成为开发团队後盾
【台湾SRE实例:Line台湾】如何确保Line服务天天不中断,专责SRE扮演开发与维运的桥梁
Line台湾百亿笔遥测数据的可观察性平台架构大公开
台湾大型企业如何上手SRE,Google建议先做这4件事
SRE-BOOK
Operations Anti-Patterns, DevOps Solutions
Logging and Log Management
阿里云-日志服务
Grafana Documentation
Prometheus
Loki Documentation
FluentBit Documentation
You can find me on
>>: X.509 标准中未定义可分辨编码规则(Distinguished encoding rules)
再现性是指在这个模型产生出来以後,由不同的开发者或利益相关者,重新创建相同 ML 模型的能力。这其中...
前言 所谓工程师就是,想到一个点子之後一直囤着、欠了一屁股技术债、init一堆新的side proj...
你还在看,真有心,来吧! 我们一起牵手向前行! 读取委托回报,通常下单(raplace order)...
今天开始来写出自制的卷轴,构想是这样子的 根据构想先把框架写出来 <div class=&qu...
为何需要环境变数 ? 若你的专案有使用到 DataBase 服务,在程序码里会撰写 Connect ...