运营数据包括(云上的DevOps人为什么会崩溃？)

云上的DevOps人为什么会崩溃？

　　DevOps 与云，似乎有种浑然天成的特质：二者都追求“弹性敏捷”、“软件即服务”、“软件定义一切”。一个是引领了“持续集成”、“持续交付”的企业文化的变革理念，一个是高并发高可用场景下，事实上的主流应用开发的基础设施。二者一旦有了同样的地秉性，就“手拉手”一起大步向前奔赴未来。　　技术的变革，好比马车与火车的变革。如果能及时迁移到新技术上来，新技术所带来的成长将不日而语。但显然并不是所有人一上来就能接受这种变化。　　正如​《云原生改造到底有多难 | T前线》​​一文中，作业帮基础架构负责人董晓聪所说，“云原生的转型改造，会对运维的方式产生一定的影响，对于运维岗位而言，中等规模的公司的是很难一下接受的。人肉的工作少了，基础架构的能力更得到重视，不再局限于一些重复的、机械式的工作。”　　传统的运维，更多的是指网络运维、数据库运维等。而现在我们在招聘软件上再搜索“运维”，呈现给求职者的，更多是“云原生运维”、“ DevOps 工程师”、“SRE工程师”、“云原生架构师”、“ Kubernetes 运维”等字眼。 当传统时代让渡给“云”，与之相关的运维工作的内容和职责都产生很大的不同，短短几年间，传统 Linux 操作系统的运维方式的聚光灯移开，取而代之的是云原生时代的 Kubernetes 的运维。　　云上的 DevOps 工作内容因各家企业的实际业务不同而不同，但 Kubernetes 运维作为事实上的云运维标准，这里作为一个典型来进行介绍：　　熟悉 DevOps、CI/CD，负责应用产品的持续交付和持续运维的工具体系的建设，支撑业务的快速迭代与稳定性工具建设； 完善 Kubernetes 集群的监控体系、日志分析和全方位数据运营（包括可用性指标、历史事故、资源利用率等），提高监控有效性及时发现故障，保障业务可用； 优化 Kubernetes 集群运维体系，对底层基础组件的部署持续调优，提升各线的运维能力和问题处理效率； 负责 Kubernetes 集群运维平台的建设，打造自动化运维和管控体系；负责Kubernetes集群管理、部署发布、可观测体系等系统的设计和实现。　　云上的 DevOps 远远不限于这些。　　然而，鲜花与荆棘同在，弹性、可观测、韧性、可持续等一系列高档的词汇都会出现在它的上下文。但回归到落地层面，犹如一种“云泥”之别。 许多在做数字化转型的公司，往往急于改造，却忽略了实际业务情况，强行把“DevOps”塞到云中，结果往往适得其反，崩溃得的一塌糊涂。比如：远程会议中　　首先是显而易见的问题：人才。 要在云中进行 DevOps，云运维工程师需要对于懂得非常专业的基于云的工具以及并构建工具链相关内容非常专业。如果做不到，一切都是泡影。 公司要在传统运维人员中找到具备这项能力的员工，并不容易。更糟糕的是，有的公司甚至将 DevOps 撤回到传统平台，宣告失败。 其次，大多数 DevOops 工具链所需的工具，云很少拥有。虽然现在云上已经拥有不少 DevOps 工具，它们要么由公共云供应商销售，要么由 DevOops 云服务的主要合作伙伴销售，但研发人员往往会发现一个问题：你所需要的大约 10% 到 20% 的工具，并不存在于你的公共云平台上。这时你就将不得不合并另一个提供商的平台，这会导致多云的复杂性。当然，对那些缺少的工具的需求取决于当时正在构建的应用程序的类型。 当然，DevOops 工具提供商看到了云计算的成功，并迅速填补了这项“工具短缺”的空白。但是，通常不可能在首选提供商上找到本地运行所需的一切。Devops 工程师通常会选择混搭的方法，采取“云优先”策略： 如果可以找到，他们会选择在云上本地运行的工具，但在其他云提供商或那些可怕的本地系统上则配有后备选项。 再加上代码和数据，在云和其他远程系统之间来回传输，这种由工具链带来的复杂性，将会放大到相当棘手的难度。 这时，次生的问题产生了：如果你没有了解云安全部署的员工，安全性和可靠性又成了一个挑战。 总之，自制应用程序和基础设施与基于云的 SaaS 之间的差距，比想象中的要大。在没有找到合适的人才之前，决策者不能头脑一热，就把 DevOps 搬到云上。　　最近几年，疫情对企业的数字化转型具有明显推动作用。不同行业都反映出一个事实：越早进行数字化转型越有利于在业务中领先。而在此这种背景下，传统的IT运维就显得力不从心了。　　首先，随着企业数字化转型的发展节奏提速，IT系统数量快速增长，同时云原生架构的应用导致系统复杂度越来越高，传统运维方式已经无法满足业务发展的需求。提高运维效率和运维质量，成为IT运维的必然趋势。 其次，传统运维依赖于人的经验，这使得业务的稳定性、安全性难以得到保障，阻碍了数字化转型的进程。 最后，传统运维不能从业务服务的视角去看待整体整个的数据变化，很难第一时间判定问题根因。所以必须改善传统运维的效能，才能满足数字化转型的要求。　　那么，云中的DevOps人怎么样呢？　　他们就是或者说，在大小长假和“购物节”期间，保障全民线上狂欢的幕后工作者——云运维工程师及各重保团队的工程师，。是怎样的状态呢？　　云计算时代对运维提出了新的要求，云运维将在本地工作转移到云服务器端，从基础架构到上层业务，管理对象增多，包括了存储、虚拟机、网络安全、防火墙、备份、缓存、负载均衡、数据库等等......　　与此同时，架构云化和智能化提高了运维的门槛，要求运维还需具备纵向的管理能力，对此进行统一监控，快速定位问题所在。因此，运维需要一个强大的平台作为支撑，通过自动化部署进行生命周期阶段的操作，按需配置与更新云端资源，对现有的维护模式进行延伸，解决云运维维护的困境，保障业务持续发展。　　具体到职位，云运维工程师 15k 起步，专家和架构师的薪资则在 25k 到 40k 不等。 不管是传统的运维还是云运维，工程师们的“随时待命”状态还是一样的。“除夕家人在家吃年夜饭。工程师一边看春晚，一边守在电脑旁看监控系统”成为了新的运维工作常态。而疫情的影响，人可以下班回家，但往往也需要“远程值班”。 如果你正在云厂商任职，上云全过程进行管理和技术支持工作、定期与重大客户深入交流也成为了一项十分重要的工作。　　首先，需要熟悉 IaaS、PaaS、SaaS各层的架构及典型应用。 其次，基础功扎实的人员。熟悉安全、Linux系统、数据库、云服务、大数据等，熟悉基础组件（Nignx、Kubernetes、Redis、消息队列、MySql等） 再者，拔尖的高分项。经历过大中型企业业务场景，良好的协作和推动能力，比如针对客户现有IT架构进行梳理与分析，推动售前架构师所提供的设计方案的落地、设施和交付工作等。 再比如，对AWS、腾讯云、阿里云等不同品牌的云服务区别，形成了不错的认知。 最后，实战经验。如果你具备丰富的企业级应用架构设计或云服务集成实施经验，那在谈薪阶段，主动权往往掌握在你手中。　　去年，阿里云发布了“云上自动化运维白皮书”，其中写到： 65%的企业已经在公共云中 使用DevOps，却只有 20% 的企业认为自己充分用到了 DevOps 的全部能力。 云和DevOps的结合，发挥双重价值的同时，也带来了很多诸如“统一简单的可观测”、“分布式应用的复杂性非常高”、“链路复杂度高”、“缺乏自助服务”等挑战。 新需求是点亮技术演进树的触发点，开发者从来不担心会有新更趁手的工具的产生，他们更多需要的是——在转型决策之前，从容不迫地理解各种“云事物”，不止工具，还有文化与理念的变化。　　参考链接：　　​​https://www.zdnet.com/article/cloudify-devops-6-4-arrives-heres-whats-new​​​​https://www.infoworld.com/article/3674690/how-devops-in-the-cloud-breaks-down.html​​​​https://www.zhihu.com/question/430000480/answer/2627883101​​​​https://zhuanlan.zhihu.com/p/469897872​​​​https://zhuanlan.zhihu.com/p/339177612​​　　来源： 51CTO技术栈