“云原生”架构下，IT运维还存在吗？
学习资料：IT运维管理社区专家讲堂直播300期视频回放
“云原生”架构下，IT运维还存在吗？
最近多次被问到：“云原生的逐步完善、DevOps的深度应用，那么NoOps（零运维）的时代是不是真的会来临，作为运维人我们该如何应对这种趋势呢？”。云原生的架构持续浸入到数字化转型应用中后，IT运维是不是真的就没有了呢？这个问题仁者见仁，智者见智。但我个人认为，如果我们能先充分理解“云原生”后，那么再思考“云原生下，是不是真的就是不需要运维”，会更加准确。
什么是云原生？云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。云原生的关键特点？Pivotal公司的MattStine于2013年首次提出云原生，其定义的云原生4个要点是：微服务+容器+持续交付+DevOps。
微服务：几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，微服务有理论基础，那就是康威定律，指导服务怎么切分，是组织架构决定产品形态。微服务架构的好处就是按Function切了之后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据DDD来搞。
容器化：Docker是应用最为广泛的容器引擎，容器化为微服务提供实施保障，起到应用隔离作用，K8S是容器编排系统，用于容器管理，容器间的负载均衡，Docker和K8S都采用Go编写。
DevOps：这是个组合词，Dev+Ops，就是开发和运维合体，不像开发和产品，经常兵刃相见，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。
持续交付：持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。
实际落地中，符合云原生架构的应用程序的特点是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。
为什么会出现云原生，解决了什么痛点？我们先从云计算说起。在云计算普及之前，一个应用想要发布，就需要企业自己先买几台服务器，并放入IDC机房中。接下来就是装Linux系统，部署应用。我们就假定用Java写了Web应用，怎么部署上去呢？先配置Tomcat服务器，在把编译好的war包上传到服务器，有用FTP的，安全意识高一点的会选SCP，然后配置Nginx、MySQL这些服务，最后一通调试，把应用跑起来，就算齐活。这种物理机配合自搭网络环境、自搭Linux、自配环境的方式，有很多缺点，但最主要的痛点有这么几个：
[*]扩容和维护难。因为是物理机，需要先采购后安装到机房，遇到业务量猛增是来不及扩容的，用术语讲就是计算资源缺乏弹性；
[*]安全性太差。熟悉Linux的运维工程师本来就少，精通SELinux的更是凤毛麟角，而且，系统安全性仅仅是一个方面，应用部署的权限、流程造成的安全漏洞更大；
[*]需求不能快速响应。开发、测试和运维脱节，缺少自动化测试和部署，应用系统的上线部署是大变更，涉及非常多的准备和多轮的测试，直接导致无法快速迭代业务。
解决方案是上云。上云不能解决所有痛点，但部分解决了前两个痛点：
[*]比起物理机，虚拟机的创建、维护、销毁比物理机简单了太多，且随时可以扩容，很大程度上解决了“弹性计算”的问题，至于弹性程度有多大，还得看应用的架构和设计水平；
[*]和绝大多数中小企业相比，云服务商在网络和服务器安全方面要强若干个数量级。只要选择合适的官方镜像，配合防火墙规则，系统级别的安全问题大大减少，可以将重点放到应用本身的安全性上。
那么第三个痛点“不能快速响应业务需求”云计算就不能很好的解决了，要实现持续交付、快速迭代，是需要应用架构、软件开发的方法都需要改变才能实现，这时云原生的“微服务、容器”等特性的优势就体现出来。
使用云原生后对应用系统开发的带来哪些变化？1.本地部署的传统应用往往采用c/c++、企业级java编写，而云原生应用则需要用以网络为中心的go、node.js等新兴语言编写，但并不是说Java不能用，只是说GO语言对云原生适配更好。2.本地部署的传统应用可能需要停机更新，而云原生应用应该始终是最新的，需要支持频繁变更，持续交付，蓝绿部署。3.本地部署的传统应用无法动态扩展，往往需要冗余资源以抵抗流量高峰，而云原生应用利用云的弹性自动伸缩，通过共享降本增效。4.本地部署的传统应用对网络资源，比如ip、端口等有依赖，甚至是硬编码，而云原生应用对网络和存储都没有这种限制。5.本地部署的传统应用通常人肉部署手工运维，而云原生应用这一切都是自动化的。6.本地部署的传统应用通常依赖系统环境，而云原生应用不会硬连接到任何系统环境，而是依赖抽象的基础架构，从而获得良好移植性。7.本地部署的传统应用有些是单体(巨石)应用，或者强依赖，而基于微服务架构的云原生应用，纵向划分服务，模块化更合理。
所以，云原生应用后貌似所有现在面临的运维棘手问题都不存在了？目前云原生使用情况怎么样？之前看过一个针对国内中大规模企业调查报告显示“60%以上的用户已在生产环境中应用容器技术，1000节点规模的容器集群能够满足近8成用户的生产需求”。作为容器最主要的应用场景，8成用户已经使用或计划使用微服务。同时，Serverless技术显著升温，近3成用户已在生产环境中应用，但用户在Serverless化部署的过程中仍面临诸多挑战。”Gartner更是预测“到2025年，95%数字化运维将通过云原生平台进行支撑”。这个数据和我目前接触到的客户的应用情况差不多，无论是ToB还是ToC，无论是标准化产品还是定制化产品，都在大踏步的进行云原生的改进，最重要的理由就是：“能快速迭代，持续交付”。
使用云原生后对IT运维带来哪些变化？云原生运维要解决几个关键问题：1.标准化：标准化可以促进开发团队与运维团队的沟通和协同，标准化也有助于生态分工，推动更多自动化工具的出现。2.自动化：只有自动化运维，才能支撑互联网规模的挑战，才能持续支撑业务的快速迭代与稳定性。3.数智化：数据化、AI增强的自动化运维成为未来发展的必然趋势
上述的几个问题对于运维人的变化是：
[*]工作思路的变化
原来以标准化的工作过程来协同人高效完成工作，转变为通过标准化的过程来实现自动化；
[*]传统以故障为核心的维护，转变为以快速交付为核心；
传统以知识积累来提升团队能力，转变为通过开发自动化处理模型来训练AI来完成运维能力提升；
[*]技术栈的更新，运维开发工程师将是未来的主要运维团队
微服务、多云环境、IaaS下，无论是应用系统还是基础设施都被切分为足够小的业务服务，以实现持续交付和迭代，这样传统的人工运维的方式已经无法管理如此多的对象，运维工程师必须要能够在原有维护对象专有技能的基础上，无论是软件运维、服务器运维、操作系统运维还是网络运维，都必须要执行自动化运维，而业务的差别也就无法使得运维工具标准化。因此，运维工程师必须要有一定的开发能力。而对于流程也是，传统的业务都是由人工来协同完成的，而云原下，各个板块的工作都是对应自动化工具完成。这样运维流程经理在具有原有流程能力的基础上，必须要有能力去编排不同的自动化组件以实现从资源准备、软件部署、自动化业务验证（测试）的一系列工作。也许，运维的工作不会消失，但云原生下运维工程师不具备编程、开发能力将寸步难行。
[*]运维工具生态的重新洗牌，低代码开发平台将成为主流
传统的运维工具，无论是监控还是运维流程，都是通过标准化的产品以保障业务的稳定，确保快速响应为核心，云原生背景下，故障、性能都会被自愈处理，而业务的差异也就使得自愈处理的过程不能统一，必须要通过二次开发来完成，那么运维工具的二次开发能力将决定工具是否能落地。
写在最后
数字化转时代已经来临，扫码加入我们吧，全新思维方式学习ITIL4，数字化转型时代必须掌握的新技能。
页:
[1]