阿里云经过9年多的发展，成长为中国第一全球前三的云服务提供商，为上百万用户提供IT基础设施云服务。这些用户几乎都会使用ECS弹性计算服务，这其中既有面向消费者（to C）、企业（to B）提供服务的互联网应用、电商、娱乐等类型的用户，也有面向企业内部效率提升搭建信息化数字化平台和应用的用户，还有广泛的个人网站、开发者等，不论哪种类型的用户，从创建第一台ECS云服务器开始，就已经进入了云上运维的阶段。
业界从不同的视角总结出ITIL、DevOps、SRE等系统的运维运营体系，相信很多运维同学都在各自领域探索将这些理念和方法论落地实践。伴随着从On-Premise环境到云上环境，一方面，不论哪种方式始终未变的是运维的本质——为业务发展提供稳定可靠的支撑，保障业务永续运行，并通过有效的手段提高效率并降低成本。而另一方面，由于基础架构运维的对象如数据中心、服务器、存储、网络设备等变为阿里云提供的弹性计算服务，在运维的关注点、方法、工具等方面确实发生着改变。
与传统IDC环境相比，云上运维有哪些差异？大量的计算资源怎样方便快捷地部署、管理？如何发挥弹性响应业务负载变化的同时保持较低TCO总拥有成本？ECS出现异常是什么原因，如何保持业务连续性？……等等这些，是很多用户在使用和运维ECS过程中提出的问题。从用户的声音中，我们听到用户对稳定、弹性、透明的诉求，我们也在不断升级ECS的运维能力和体验，助力用户建立主动运维体系，赋能业务永续运行。
1 您的系统做了哪些高可用设计和故障响应机制来应对各类异常故障，比如服务器的非预期宕机？效果怎么样？
2 您的系统所支撑的业务存在经常性的负载变化吗？是使用弹性伸缩服务还是自己实现一套应对机制？
3 您如何在ECS上做应用发布部署，是将新的发布做成自定义镜像，或者使用userdata在实例创建时做初始化部署，还是利用第三方工具在运行时部署？
4 这个过程中你觉得阿里云有那些可以做得更好的吗？
带着这些问题，8月8日在阿里云自动化运维产品发布会上阿里云高级产品专家张鹏程(践远))将分享ECS升级主动运维能力
主要针对企业运维人员，通过阿里云提供的实例健康状态、系统事件等丰富信息，及时感知ECS实例的运行状态和变化影响，并基于ECS丰富的API和部署编排能力自动化响应，使云上运维更精细、更智能，保障业务永续运行。
发布会地址：https://yq.aliyun.com/webinar/play/485
淘公仔 x 1
星座淘公仔 x 1
福禄寿淘公仔 x 1
黄一刀
复制链接去分享
1 您的系统做了哪些高可用设计和故障响应机制来应对各类异常故障，比如服务器的非预期宕机？效果怎么样？
我的系统通过应用集群和数据集群来应对各类异常故障。在单节点异常的情况下，系统还能继续正常运行，而且能很好的应对分布式攻击。
2 您的系统所支撑的业务存在经常性的负载变化吗？是使用弹性伸缩服务还是自己实现一套应对机制？
每年都有固定的几个点负载加大。通常都是通过临时提升CPU、内存、带宽来应对；
3 您如何在ECS上做应用发布部署，是将新的发布做成自定义镜像，或者使用userdata在实例创建时做初始化部署，还是利用第三方工具在运行时部署？
我们有专门的软件，通过文件比对替换掉旧的文件，通常都是局部更新。
4 这个过程中你觉得阿里云有那些可以做得更好的吗？
一个是阿里的高防价格太昂贵了，我们通常都是自己通过技术手段来应对，另外一个是阿里对于ECS的负载没有预警，负载一旦达到极限，应用就崩了。
ps：想要那只大黄鸡。
rippletek
复制链接去分享
1 您的系统做了哪些高可用设计和故障响应机制来应对各类异常故障，比如服务器的非预期宕机？效果怎么样？
综合运用“云计算十字真言”中的“冗余“和”漂移”，服务器宕机完全无感知，运维机器人甚至可以经常重启或关闭线上服务器。
2 您的系统所支撑的业务存在经常性的负载变化吗？是使用弹性伸缩服务还是自己实现一套应对机制？
各个服务的负载情况和变化趋势很不相同，使用“云计算十字真言”中的“伸缩”实践，运维机器人自动处理伸缩。
3 您如何在ECS上做应用发布部署，是将新的发布做成自定义镜像，或者使用userdata在实例创建时做初始化部署，还是利用第三方工具在运行时部署？
全面使用容器化部署，发布系统制作好容器镜像后通知容器调度系统进行部署，可实现无感知漂移上线。
4 这个过程中你觉得阿里云有那些可以做得更好的吗？
在容器计算的方向上可以跟得更紧一些，比如支持最新的minimal ubuntu系统。
上面提到的各种实践方法在这篇文章中有比较详细的介绍：https://yq.aliyun.com/articles/62686
痞子姜
复制链接去分享
1 您的系统做了哪些高可用设计和故障响应机制来应对各类异常故障，比如服务器的非预期宕机？效果怎么样？
集群、熔断、降级+故障自动重启，和以前相比，故障减少了，服务可用性明显提升了，机器的负载能力也提升了
2 您的系统所支撑的业务存在经常性的负载变化吗？是使用弹性伸缩服务还是自己实现一套应对机制？
存在，跟交通打交道，人流、车流多，数据量就飙升。使用弹性服务和自己的一些熔断机制来减轻压力，把对时效要求不高的任务往后排一排
3 您如何在ECS上做应用发布部署，是将新的发布做成自定义镜像，或者使用userdata在实例创建时做初始化部署，还是利用第三方工具在运行时部署？
Jenkins+gradle，采用第二种方案
4 这个过程中你觉得阿里云有那些可以做得更好的吗？
降低费用，提供免费额度，像七牛云那样，为个人开发者赋能
浮生递归
复制链接去分享
1 您的系统做了哪些高可用设计和故障响应机制来应对各类异常故障，比如服务器的非预期宕机？效果怎么样？
主要是先前期调研好一个系统的各个时间节点，在不同的峰值进行针对行的解决方案。比如单纯的高流量，就提前设置好临时带宽升级。一些日期比较确定的系统，比如报名系统，用这种方式，可以一次设置，全年无忧。
对于非预期宕机，主要采用监控报警的方式，宕机了，就让技术人员赶紧上去排查原因呗。
2 您的系统所支撑的业务存在经常性的负载变化吗？是使用弹性伸缩服务还是自己实现一套应对机制？
我的系统有的应用负载变化非常明显。最大的就是报名系统的选位功能吧。一年里只有几天是报名时间，其他时间，访问量几乎为0。但是报名期间，特别是选位那一天，在选位功能刚开放的那一分钟，访问量会瞬间突破到上万。今年用了比较Low的解决方案，明年准备用负载均衡了。
3 您如何在ECS上做应用发布部署，是将新的发布做成自定义镜像，或者使用userdata在实例创建时做初始化部署，还是利用第三方工具在运行时部署？
现在都是用初始化部署的方式，但是现在感觉到这种方式很不方便，估计接下来会采用自定义镜像。
4 这个过程中你觉得阿里云有那些可以做得更好的吗？
目前应该做不到，将来能实现吧，当服务器宕机出现故障，希望阿里云的系统能够自动解决故障，恢复运行。这样就没我们运维什么事了，哈哈。
1875333287957704
复制链接去分享
免费申请服务器在哪申请啊
如果是学生的话可以申请学生机；如果不是，这里有优惠券，https://promotion.aliyun.com/ntms/yunparter/invite.html?userCode=fk1p2n5w
markds
复制链接去分享
1 您的系统做了哪些高可用设计和故障响应机制来应对各类异常故障，比如服务器的非预期宕机？效果怎么样？
有些跑在容器上的应用利用集群本身的HA，有些站点服务利用站点检测，设定合适的告警阈值，收到告警立即通知业务相关人员排查原因。
2 您的系统所支撑的业务存在经常性的负载变化吗？是使用弹性伸缩服务还是自己实现一套应对机制？
每年有几个点，负载会有突增的情况，临时调整带宽资源可以应对。对于弹性伸缩需要应用本身支持才有效果。
3 您如何在ECS上做应用发布部署，是将新的发布做成自定义镜像，或者使用userdata在实例创建时做初始化部署，还是利用第三方工具在运行时部署？
应用发布不是很频繁，应用发布过程还是比较传统。
4 这个过程中你觉得阿里云有那些可以做得更好的吗？
云监控在实例界面有显示可能更好，只要一个ECS被创建都应该被监控。
aoteman675
复制链接去分享
1 您的系统做了哪些高可用设计和故障响应机制来应对各类异常故障，比如服务器的非预期宕机？效果怎么样？
我们有自己的机房，目前最好的方法就是集群，用分布式解决。我们的服务器用了负载均衡，服务器够用。
2 您的系统所支撑的业务存在经常性的负载变化吗？是使用弹性伸缩服务还是自己实现一套应对机制？
个别业务大的服务器就是增加配置，临时增加专线带宽。
3 您如何在ECS上做应用发布部署，是将新的发布做成自定义镜像，或者使用userdata在实例创建时做初始化部署，还是利用第三方工具在运行时部署？
有时候用自定义镜像，一般情况下都是用版本工具发布
感谢您的介绍！您提到阿里云对于ECS的负载没有预警，这部分您有使用云监控来设定一些监控告警吗，还是负载增加后告警不及时导致您应用受损呢？
有设置，就是告警不及时。