携程基于应用的自动化容量管理与评估已校对

各位下午好，我来自携程运营中心，今天跟大家的题目是基于应用的自动化容用不健康，其实不算是好的容量管理。背景上的很多问题是我们在日常工作会经常自省对运营一个来说，业务规模会不断地增长，服务器数量会随之同步增长，然而资源的使用率则会逐步下降。因为一开始考虑的是生存，能实现功能，不至于频繁宕机就好，慢来的，就是服务器数量会增加，使用率逐步下降。首先，追求应用的响应速度。像前一位的同学提到的CDN会非常依赖响应速度，经常有很多分析响应时间每提升1ms，收入就能增加多少，所以就采用过量提供资源如开发需求的变更，或者对未来的业务量估计不足等等，需要给自己留一些buffer。这些都是可以理解的，但却既费钱又不环保。IT系统一向被认为是高效清洁的技术，但IDCIDC各位有没有大致统计过自家服务器的平均使用率？去年计算所的一份指出，IT12%100上，却只有12块是真正用在需要的地方。初步估算一下，以目前携程的体量，CPU1%，节省下来的能耗和计算资源，足以提供13000人一年的生活用电。携程目前的体量还不算特别的大，如果换成显而易见，提高使用率也不是越高越好，那我们的度在什么地方？的度就在于满足上层服务的稳定性、可靠性的要求，这是我们的。只有在这条之上，我们才可以去进一步考虑怎么来提高它的使用率。IDCDR40%，即确保在任何情况下，一旦某个IDC宕了，另外一个必须能够承担所有流量来支持应用的请求，这样基于这个前提以及业界的一些数据，我们认为实际使用率25%以下为安全，超过30%需警惕，达到40%则很，不管怎样都需及时扩容。而使用率不足20%则是对资源和电CPUI/O、参数配置这是一个逻辑架构图画的比较简单，大概解释一下，就是在生产环境上，通过控制前端负载均衡器上的权重，来控制流量分配，用生产环境的流量对集群中某一台服务器上的应用进行压测，并在实时应用性能指标，任何一个系统资源到达瓶颈，比如CPU连续5CPU20%60%左右，其实并没有达到瓶颈。下面两个指标是应用非常关重合的，响应时间没有变化，所以这个应用在5倍量请求下是完全可以承受的，包括后面出错率也基本上是零。基于这样的结果开发人员可以非常明确地知道，我这个应用在5倍压力下是安全的，会有一个靠谱的心理预期。其实从这个结果来看，567是量TPS，纵坐标是系统各项性能指标，我们给每个资源都设置一个阈值，当量不断增加时，必然会有某一项资源最先达到瓶颈，我们用整个过程中的数据给APP1建立一个APP2多个应用之间的关系无非是相关或者不相关。所谓相关是一个应现实情况是，CPU应用，才的描述里面大家可以有这个答案了，就是我们用一个TPS的指标，来替换掉传统概念中的CPUTPS其次是我的生产环境上了一些新的版本之后性能变好了还是差了？对于当前版本代码在200150VM10钟以内。也就是说，从开始申请服务器到新的资源投产正式分担流量控制在10分钟以内。那可能有些同学会有担心，我们没有给开发人员做任何的资源使用限制，会不会最后导致开发不重视代码性能，资源被？从我们运维的角度来讲，开发人员就是我们的客户他们需要资源，我们实际上是没有理由驳回的，只能全力支持。那是不是意味着会被任意挥霍呢？其实不会，我们限制不了，但有一双无形的手可以限制，对，就是财务。CPU果有一点是必须要先做的，那就是系统层和应用层的性能数据和搜集。否则以上的一切我们拥抱智能化的运维时代？我的就到这里，谢谢。，梦寐以求想知道我的应用跑在生产上是什么状况，如果只是在测试环境不知道这个代码，比如某一个应用跑端集群上面，对后端哪台服务器是被打散掉的，所以这个流程是不管后端状况，前端。机器的总体处理能力比如每分钟1万TPS，但是看历史最高流量可能只有一千个，提问：那如何排除历史版本或者是一些历史的最高，但是往往历史最高的时间点觉得这样的话历史的那套可能参考价值不会100%达到那么大。者量用户的体验，所以我们这边