“对于着手之前需要先行学习的内容,我们往往会选择在实践过程中学习。” –亚里士多德
今天的实践清单也可以被命名为《我在踏上云之旅程时所应了解的十项内容》。幸运的是,我们当初恰逢与道琼斯共同起步,并从其身上学到了大量宝贵经验。其它知识则源于我们自己的亲身积累。自从去年九月加入 AWS 以来,我得以同几十家客户进行了探讨,并在最具转变性——以及保守性——的状况之下见证了 AWS 显著的属性增强效果。
- 管理层大力支持。这一优势适用于大部分具体项目。大型企业中的实践项目往往会在公司老总表示支持时获得更为理想的成功机率。大家用不着逼着自己在头几个月就做出成效,云技术项目的最终目的是为了让企业最终在业务层面取得成功。因此,我们需要引导企业意识到这是一项马拉松式的长期工作,坚持到最后才能迎来丰硕的果实。
- 以员工为依托创造出卓越中心。现有员工不具备相关技能并不代表他们无法在日后的实践过程中积累到相关经验。他们能够快速转化为卓越中心、获取最佳实践并对现有治理手段加以巩固。尽管云项目在打理过程中与传统工作存在诸多差异,但其作为计算资源体系的本质并没有任何不同。我们不妨将云技术项目视为一项扩容性投资,旨在企业的现有处理能力。在这方面,合作伙伴与咨询师能够起到显著的帮助作用,特别是在加快业务成果或者业务独立性层面。不过需要注意的是,大家务必要拥有属于自己的全面云专业知识。长久以来,关于这方面工作的最佳实践方案一直引发着广泛讨论——DevOps、双峰 IT 以及全堆栈工程等等。基于我的个人经历,大家并不需要马上在以上具体方式层面做出选择。我们完全可以将其作为企业转型或者增添其它运营途径的良好机遇。大家对于自己的业务体系无疑最为熟稔,因此一旦获得了相关专业知识,正确的发展道路要自然呈现在各位面前。我将在其它后续文章当中就这一思路展开更为详尽的探讨。
- 不要过分关注具体成果的实现速度。请记住,云技术发展是一段漫长的旅程。那些已经决定“全力施为”或者将基础设施中的关键性部分迁移至云环境当中的企业绝不是一拍脑门就做出了选择。他们以实验性项目为起点,在尝试过程中了解云技术的价值,并在将相关责任机制推广到整个组织体系的同时逐步掌握由此带来的收益并实现容量增长。
- 解放思想,以开放态度迎接新技术。业界一直在就哪些项目类型最适合云技术而进行碍讨论。大家应当从中选择那些切实符合业务需求,而非从直观感受上似乎更加合适的方案。选择的可能性几乎是无穷的,我们可以将领导团队作为驱动因素,也可以在企业内部单独建立一个由团队或者个人扮演的项目应用角色。如果有人认为自己能够在云环境下完成业务目标,那就放手让他们去试试。大家可能会发现,我们确实值得去主动发掘这类乐于探索的员工,并为他们提供证明自己的机会。通过这种开放的态度,大家往往能够获得不少意料之外的惊喜。
- 以谨慎的态度进行成本比较。在内部与云基础设施之间就总体拥有成本(简称 TCO)做出明确分析。我见到的一类常见陷阱在于,当企业对现有内部基础设施进行成本核算时,他们往往无法准确区分未被充分利用的资源与必要的预备容量间的区别。举例来说,如果大家的系统每天需要面临为期四小时的峰值时段、在此期间要求六台服务器全力运转,但除此之外的二十个小时中只需要两台服务器即可完成日常处理任务,那么我们每天所需要的服务器计算时为(4 * 6 + 20 * 2)即 64 单位。从这个角度来看,总体拥有成本的计算方式应该使用 64 服务器计算时,而非传统意义上的 6 * 24 即 144 服务器计算时——几乎只相当于传统计算需求的一半。即使大家的计算环境下存在着大量虚拟化系统,同样有可能为了保证充足的按需资源余量而背负上沉重的额外容量拖累。我们在云部署方面走得越远,这方面浪费的出现机率也就越低。AWS 以总体拥有成本为核心构建起卓越中心,而且乐于帮助客户在这方面作出准确统计。尽管此类工作看起来更像是种自助式服务,但 AWS 仍然能够提供大量专业知识与最佳实践,并以此勾勒出足以指导实际应用的完整图景。除此之外,如果大家找到其它更加划算的资源使用方式,AWS 也乐于从中学习并借此改进自己的服务性价比。感兴趣的朋友可以点击此处查看我们的相关基础工具。
- 不畏惧错误,并为此做好准备。这是种良好的心态。大家在获得专业知识的同时,必然也会错失其中的一部分内容,而且往往发现自己的部署节奏会变得越来越快。我们并不是说交付过程应该越慢越好。事实上,很多 AWS 实验性项目在交付速度上要远远超过传统解决方案所能允许的水平,在此期间甚至有可能引发一系列问题。云计算带来的显著收益之一就在于,实验过程中带来的成本相对更低。很多最具创新活力的企业认为实验正是创新工作的重要素材来源。如果某些要素无法确切起效,大家无需太过纠结、继续前进便是。尝试的过程没必要牵涉太多功利性的考虑。
- 让自动化机制成为一种前提。自动化是企业在充分发挥云计算优势时最值得关注的重要技术转变之一。根据我个人的经验以及与客户间的交流结果,一旦某家企业开始将自己的服务器基础设施视为计算实例集合而非简单的机器堆积,那么弹性就将成为一大显著收益。此类解决思路能够带来更为出色的安全水平、实现环境的可预测性并发挥自动规模缩放效果。在我看来,规模的自动缩放是有史以来最伟大的创新成果之一。这是一类最为根本的新特性,云计算正是借此树立了自己的稳固根基。与原有总体拥有成本相比,这种优势能够极大巩固企业客户对日常成本的缩减能力。
- 以积极态度进行监控,并为关注点设定警报。每一家企业都拥有自己独特的关注点以及风险容忍能力。大家可能最关注有多少人能够按照预定计划获取到划拨资源、服务账单的实际变化情况或者是网络或应用程序中的特定部分在资源敏感度方面是否比其它部分更高。无论实际关注点如何,大家都应当在团队当中对其作出强调,并确保利用适当的工具(例如 CloudTrail、CloudWatch Logs、Directory Service 等等)作为辅助。
- 充分运用 AWS Marketplace。这套 Marketplace 当中包含着大量适用于全部 AWS 客户类型的常见问题解决方案。当道琼斯方面被迫弃用其设施之一时,我们得以找到一套替代性软件方案——在此之前,我们一直以为 AWS Marketplace 当中只提供纯硬件解决方案。其使用过程非常简单,基本上与加载一套配置差不多。日常管理实践并没有出现任何变化。大家会惊讶于 AWS Marketplace 当中那些宝贵资源在加快项目进程中带来的出色表现。
- 积极探讨,交换意见。除了技术部门之外,企业中的其它组织也希望了解到项目的发展进程,掌握哪些元素已经落实到位、而哪些尚未确切起效。分享相关经验能够在巩固议程的同时强调团队中贡献者所做出的成绩。除了应得的表彰之外,交换意见还能显示出企业在实施新技能与新举措后所获得的成果。大部分 AWS 客户都会以公开方式探讨自己已经完成的工作。这种心理层面上的成就感既极富意义,又具备良好的成本效率。最后,AWS 始终以客户为关注核心。90% 到 95% 的 AWS 路线图都由客户反馈所敲定。如果大家有更好的主意,也请随时与我们联系。
以上实践是否引起了大家的共鸣?如果各位拥有自己的见解或者独特的经历,欢迎在评论栏中与我们分享。
评论