用户视角和技术视角看问题
用户进入景区看到的是漂亮干净的古代建筑，想到的是宏伟壮观，园区维护人员看到的是墙面是不是该粉刷了，考虑的是上次粉刷距离现在多久了。用户进入景区的小卖部看到的是饮料、面包等实物资源，园区后勤人员看到的是货架上面的东西还能卖多久，是否库存充足。
诸如此类。
用户和维护人员看到的永远是两个视角的内容，因为他们本身就站在不同的视角看问题。
软件也一样。
一样会有用户视角和技术视角，技术视角就是我们程序员们的视角，程序员所关心的问题和用户所关心的问题，是一个事物的两个方面。
比如，用户在使用网易邮箱的时候，因为页面上的某个BUG导致收件箱一直为空，在用户看来，他会认为数据已经丢了。在程序员看来，数据还在数据库里面保存着，其实并没有丢失，程序员认为就是一个页面的BUG。
图自https://time.geekbang.org/column/article/372559
正如上图所示，用户视角，我能访问到什么功能，我点击功能后多久能返回结果，我最想使用哪些功能。程序员视角，系统稳定性，核心链路功能节点是否有问题，TP999有无波动。
扩容是一种进攻思维
景区的人多了，会限流，售出的票做数量限制，园区门口栅栏围上排队进入。
却不好扩容。
但，软件系统可以。
扩容是一种进攻思维，而我们常常做的保障系统稳定性措施，也就是常用的三板斧：熔断、限流和降级，则是一种保守思维。
TIP：从更广义上来讲，熔断、限流也是降级的范畴，属于降级的一种特殊情况。
另外，软件系统可以压测，提前预知系统在当前资源下的极限流量。当然，这一点景区也可以做到，他可以根据公共资源设施的负载情况来估计，比如园区的单位建筑面积、厕所的容量等等。
关于软件系统的压测需要注意的几个问题。
1、latency不是越短越好，有可能业务直接返回200了，需要关注下业务是否正确处理请求。
2、cpu利用率一直很低也不一定好，有可能磁盘或者缓存已经达到瓶颈，需要同时关注多个指标。
3、压测指标到达瓶颈时时，需要关注下施压方的cpu利用率等指标，有可能施压方到瓶颈了。
压测结束之后，软件系统就可以根据压测结果进行扩容。这个工作在服务可靠度层级模型中属于第三层。
当然，现在云原生环境下已经有弹性扩缩容，但是容量规划，压测的本质没有变，只是通过数据计算或者机器学习的方式帮助人们去自动做了识别与规划。
比如一种动态伸缩。
设定某服务的 CPU 利用率目标值为 75%，那么当 CPU 利用率超过 75% 时，就会触发策略，自动为该服务增加实例，降低 CPU 利用率；而 CPU 利用率过低时，又会缩减实例，最终将 CPU 利用率维持在 75% 左右。
再比如一种预测伸缩。
主要原理是通过机器学习的方式，分析 14 天范围内的历史负载数据，预测未来 2 天的负载指标和容量需求，每天预测一次。
但是，纵使有机器学习来帮助你做这样的事情。容量规划也是非常具有挑战性的工作。
一方面的挑战是业务增长的两种特性。
做软件系统的容量规划，不仅要看业务的自然增长，比如，随着用户使用量上升，硬件资源用量也上升。还要看非自然增长，比如新功能的发布，不定期的营销促销活动。
这两种增长就增大了容量规划的难度。
另一方面挑战是技术成熟度。
1、容量预测尚未发展到非常成熟的阶段，对容量的预估不够精确，无法支持大规模的自动化弹性伸缩。
2、弹性伸缩的风险较高，特别是缩容操作，有引发线上服务异常的可能性，甚至会直接导致事故的发生。
3、扩缩容速度不够快，无法满足快速弹性伸缩的要求。
总之，无论是人工规划，还是机器学习辅助，做容量规划有三个步骤是必须的。
必须有一个准确的自然增长需求预测模型，需求预测的时间应该超过资源获取的时间。
必须在规划中有准确的非自然增长的需求来源的统计。
必须有周期性压力测试，以便准确地将系统原始资源信息与业务容量对应起来。
记住这三个必须。
宏观视角看资源
从一名SRE工程师的角度看这些资源，会分为两种，一种是物理服务器，一种是软件服务器。
物理服务器，machine，代表具体的硬件。
软件服务器，server，代表一个对外提供服务的软件系统。
物理服务器上可以允许任何类型的软件服务器。
以大型互联网公司的数据中心举例。
一般，约10台物理服务器组成一个机柜，数台机柜组成一个机柜排，一排或多排机柜组成一个集群，一般来说，一个数据中心会包含多个集群，最终形成一个数据中心。
TIP：更大型的会有数据园区，比如多个相邻的数据中心组成了一个园区。
图自《SRE：Google运维解密》
以上是本周的学习内容。
参考资料：
1、SRE：Google运维解密
2、https://time.geekbang.org/column/article/372559
----END----
这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。
