- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
DevOps工程师的必备技能清单
长期以来,产品的运营与开发工作彼此割裂。这条鸿沟的一端是勤劳朴实的开发人员,另一端则是开发者眼中那些犹如酒囊饭袋般的系统管理员。系统管理员不参与开发,也不会与开发团队沟通,他们通常只是直接拿到代码包,然后尝试在某个位置加以运转。每一次运转尝试都苦痛万分,管理员们需要花几天时间渐渐查看日志、查找种种难以理解的错误、分析数据库查询、陷入无穷无尽的 strace 过程等。而很多时候的现实都证明,只需要定义一项新的环境变量或者添加一个新参数,问题就能迎刃而解。但圆满的是,开发者从来不会、也没有机会把情况告知管理员,后者独一了解的就是产品的名称及其用什么言语编写而成……
十年前的“DevOps”工作
十年之前,我刚开头在团队中担当管理员,当时的公司思维比较机警,我不像《IT 狂人》的剧情那样被支配在地下室某个阴暗的小房间里,而是在开发者当中拥有了本人的办公桌。从那一刻开头,我也踏上了本人的 DevOps 工程师之旅。
在公司的工作中,我很快意识到,虽然学问和技能都很重要,但从沟通及运营角度端详并影响产品的力量更值得关注。我有权提出异议、表达本人的担忧,并在距离最终交付还有很久的时候就准时向开发者传达观点或提示他们调整编写方法。这才是真正的管理员,他们不该被“囚禁”在地下室里!
现实很快证明,将产品的设计、开发与运营等元素进行综合端详,的确能够带来巨大的收益。只要每一个人都对产品担任,并清楚意识到产品将在怎样的生产环境中运转时,开发流程将真正与生产流程融合起来。这一切如今人们习以为常的思路,在当时不啻为一种文化冲击——开发者与管理员真正携起手来,天下再无难事!而这一切,都是被沟通鸿沟所严峻割裂的传统流程所无法实现的。
但假如 DevOps 只是一种灵敏开发流程,而且在其中引入了开发阶段的概念,那么 DevOps 工程师又是干什么的?DevOps 世界中的核心职责到底是什么?这就带来了另一个重要问题:DevOps 团队的抱负领袖应当是谁?
团队担任人的角色可以由中层专业人士担当,而且对职位或背景没有特殊明确的要求(可以是开发人员、管理员甚至是质量保证人员)。DevOps 之所以存在,次要目的就是填补产品在持续集成、交付以及运转周期中的种种空白。
从个人的客观角度动身,我认为 DevOps 领导者最好具有管理员背景(而非选择所谓的「技术骨干」)。以此为基础,他 / 她能够将与数据库升级、配置管理或者一切其他令开发者分心或苦恼的底层基础设备相关因素剥离出来。这里,我还要提出另一项管理员有更适合担当 DevOps 领导工作的观点:随着产品的进展与成熟,DevOps 团队也将随之扩大,因而需要投入的时间及精力会同步增长。假如指定开发人员领导您的 DevOps 团队,其将很难全神贯注连续处理开发工作。最终一个理由:管理员更易于上手 DevOps 工作,所以起步速度会更快一些。
DevOps 工程师该懂些什么?
DevOps 工程师们应当懂点什么,又该会做些什么?本文整理了一份 DevOps 工程师的技能清单,当然列举的可能不完整,只涵盖工程师们应当具备的部分核心技能。
灵敏开发准绳
这也是现代开发世界中最重要的技能之一(特殊是在近程协作开发场景之下)。其中不只包括区分 Kanban 与 Scrum 间的差异,同时也要求我们能够与团队顺畅沟通、了解客户价值、跟踪时间进度,以及整理出易于理解的工作日志、独立报告与清楚说明文档的力量。
自动化 + 万物即代码
大家应当尽快摆脱手动操作的困扰。时至今日,几乎一切日常工作都对应着自动化工具。假如找不到现成的工具,您也可以使用 Python 及 bash 自行编写。例如,假如需要创建虚拟机镜像,请使用 Packer。假如需要配置 10 台以上的主机,请使用 Ansible。假如您在 Google Cloud Platform 中创建 Kubernertes 集群,或者需要在 Amazon 上使用 CDN,请使用 Terraform 以简化操作流程。总而言之,从通过网络加载新的裸机服务器到在现有集群中部署新容器,一切都应以自动化方式进行。另外,您编写的代码应当具有可复制性与幂等性,提交内容必需经过跟踪程序的审核,且严格遵照以上要求。
云与混合架构
目前,我们发觉大多数企业都不会只使用一家云服务供应商(为了避开供应商锁定问题)。没错,一切不该简约粗暴地交给云方案处理,我们可以将服务中的不同部分运转在 AWS、Heroku 以及其他 IaaS、PaaS 与 SaaS 之上。请努力找到最抱负的处理方案,并保证能够在特定时段内完成不同平台之间的服务迁移。另外,也别忘了之前提到的自动化准绳,自动化程度越高、迁移难度就越低。
可扩展性与高可用性要求
最重要的是意识到企业能够在特定时段内承受怎样
文档评论(0)