取消
显示结果 
搜索替代 
您的意思是: 
cancel
3518
查看次数
58
有帮助
1
评论
julianchen
Spotlight
Spotlight
服务转换vs. 快速发布


云业务的弹性灵活和快速转换的特点虽然是那么的“金光闪闪的”,但是也给我们运维团队带来了配置和变更上的复杂性。以往,我们一旦在系统的初期完成了配置与部署,就能够管上一段时间。而变更更是能怼就怼回去,实在顶不住也要通过规范的流程来谨慎行事。而现在呢?由于试错的成本降低了,各种“花式”的变更需求已经成为了家常便饭,配套的配置信息也像松鼠屯粮一般妥妥地上涨。

配置


我们在过往的廉环话里有讨论过有关配置管理方面的各种实践。这里,我们着重来聊一聊和云服务有关的配置方面的问题。对于企业内部桌面云的配套设备而言,虽然很多已经做到了OOTB(开箱即用),但是一些例行的升级和资产的录入与统计,还是需要我们IT人员去持续跟进的。因此我们仍然有必要本着做一看二想三”的宗旨,搭建和维护好一个配置管理数据库。该CMDB除了能够根据后期实际需求进行各种表项和字段的扩充以外,还应当使得保存在其中的各种配置基线具有可移植性,以方便根据不同的云服务应用场景进行灵活组合和快速成型。

变更


对于有计划的服务改进所产生的主动变更,高效的云服务已经将其出错的风险、和回滚的难度都降到了最低。我们反而应当跟上或是做好诸如镜像与配置模板的修改,云存储空间池的配额和虚拟CPU/内存资源的增减,等方面的计划与记录工作。
·
· 而对于各种事故或故障所导致的被动变更,以往由于我们运维部门对服务和系统的责任比较明确,因此有着绝对的掌控能力。但是如今转到了云端, IT部门就需要根据既定的协议与云服务商事先明确好各自的职责,比如说:在什么情况下云服务商有权先采取必要的变更、再通知租户;什么情况下我们的自行变更需要备案、甚至要得到服务商的批准,以免伤及其他的租户。
·
· 测试


云服务发布之前:以往,我们需要配备专门的测试部门和人员,花费时间、腾出硬件资源、并通过购买测试软件搭建测试环境。而现在我们不但可以自行快速组建开发测试的云资源,还能购置一些24×7可用性的外部云测试环境。如此一来,我们就可以将精力专注于测试流程和内容之上,对服务的响应时间、资源利用率、容错稳定性、最大承压、和在不同负载条件下的可扩展性等方面进行全面的性能测试。
·
· 云服务上线之后:我们可以在征得云服务商确认的情况下(因为有时候不同服务商的允许策略会有所差异),做好各种漏洞扫描和渗透测试,以抵御来自纵向的外部威胁和横向的其他租户的攻击。
·
· 发布


发布方式上的转变:我们在处理云服务的更新与发布时,用得最多的就是:“让一部分人先用起来”的灰度发布模式。即:在允许一部分用户继续使用1.0版本的同时,让另一部分用户充当“吃螃蟹”的小白鼠,开始使用2.0版。如果2.0运行稳定,而且其用户体验不错,则逐步扩大范围,将所有用户都迁移到过来。可见,灰度发布方式更适合于发现、调整问题,并限制其波及面,避免被用户“吊打”的情况发生。
·
· 发布效率上的提升:由于云业务实现了我们运维的对象从传统的以“硬件设备”为中心向着以“虚拟实例”为中心的转变,因此在发布效率上,IT人员更能够从各种资源池中迅速地虚拟化出各种应用的实例,然后根据既定的策略实现自动化的部署。显然,这种发布流程有效地减少了以往由于全靠人工处理所带来的业务延迟或中断的可能性。

评论
13nash
Level 8
Level 8
规则,遵守规则,制度与执行
入门指南

使用上面的搜索栏输入关键字、短语或问题,搜索问题的答案。

我们希望您在这里的旅程尽可能顺利,因此这里有一些链接可以帮助您快速熟悉思科社区:









快捷链接