精华内容
下载资源
问答
  • 数据中心基础运维人员的职业规划
    2022-02-12 00:06:24

    毕业到如今,已经做了12年的运维工作,从一线运维到运维管理,之间不止一次有转行的想法。如今数据中心越来越多,名称也越来越高大上,从业人员也是日益增多。今天就来谈谈自己对数据中心基础运维人员职业规划的一些看法。

    基础运维人员的工作实际上更偏向物理化,机房场地、设备环境等等,这些是整个数据中心运行的基础,但往往这些岗位在各类数据中心内部实际上都不是核心岗位。很多公司和单位这类岗位都外包,要求也不是很高,最常见的就是各类以设备托管为服务特色的idc中心。但是一些重点的单位如银行总行、央企总部等对人员的素质提出了很高的要求,在十年前基本就是985硕打底。这就好像同样是当服务员,空姐的要求是高于列车上的乘务员。

    基础运维工作的日常也相对简单,当机房场地设备投产后,日常工作更多是以巡检、计划维护为主。相对枯燥简单,对应的技术更新换代也更慢,因而做久了往往觉得收获不大。确实,如果单单只做基础运维工作,更多的是重复机械式的劳动,就能应付好日常工作。但是如果自己也只满足于此,那么也就圈住了自己的成长空间。

    个人认为,如果你是做基础运维工作,并且准备长期从事这项工作,那么首先就要把自己代入到机房规划建设运维专家或者是高级工程师这个角色。规划建设是因,运行维护是果。要把自己定位为技术专家,抓住各类机会介入项目的立项、实施,及时总结各类项目建设的经验。这样未来既可以成长为高级运维工程师,也可以成长为高级规划及技术支撑工程师、高级项目经理。特别计算机相关专业毕业的朋友,要把系统架构这个概念嵌入到机房的规划建设中去,形成自己的一套经验体系。

    其次,任何时刻不要放松自己的学习,可以多考考职称证书,也许现在没用,但是未来某天他也许就发挥用处。这几年我自己也在考一些证书,凭着原来的一些积累,目前持有电子高级工程师证书,系统架构设计师(计算机高级职称),信息系统项目管理师(计算机高级职称)、设备环境(通信中级职称)、软件设计师(计算机中级职称)五个国家级的职称证书,虽然这些证书在我目前工作的国企,包括之前工作的某运营商和某行,在工资和职级上基本没用,但是通过学习,个人认为对一些知识可以系统化的学习,并且串联起自己的知识体系,总之,学习有百利无一害。像国家认可的计算机和通信各类职称证书考试,考试费一般就200来块钱,考过则终身受益。

    还有就是要善于总结。也许是年龄大了,这几年每次做完一个项目,我都会做一些总结性的工作,并且这两年开始把相关材料总结成论文发到期刊。当年读研究生的时候也就发了一篇论文,这两年则发了三篇论文,赚了千把块的稿费,自己也比较有成就感。

    不过总体而言,做基础运维工作相对跳槽不那么容易。根据我的经验,在数据中心最容易跳槽的工作是网络,其次是系统。就像我前面说的,很多地方的基础运维工作是可以外包的,如果你做基础运维工作,最好能够掌握网络或者系统相关的知识,把自己培养成一名复合型人才,拓展自己的职业空间,千万不要把自己局限在基础运维里面。

    520573bd1b75ebb5d7e3c5615bd36b34.png

    资料免费送(点击链接下载)

    史上最全,数据中心机房标准及规范汇总(下载)

    数据中心运维管理 | 资料汇总(2017.7.2版本)                                         

    加入运维管理VIP群(点击链接查看)

    《数据中心运维管理》VIP技术交流群会员招募说明

    加入学习群扫描以下二维码或者添加微信:

    wang2017bj

    6eb72ac27bc32c1fb6461139ccaa0e3d.png

    更多相关内容
  • 随着数据中心规模的空前发展,数据中心运维和...华为DCIM+利用云化、智能化技术重新定义数据中心管理系统,为数据中心提供了创新的运维管理解决方案。随着数据中心规模的空前发展,数据中心运维和运营也面临着严峻的...
    随着数据中心规模的空前发展,数据中心运维和运营也面临着严峻的挑战。管理者普遍关心的两大核心问题:如何让运维团队安全管理超大规模数据中心,如何最大化发挥数据中心资源的生产价值。面对挑战和核心问题, 华为全新数据中心管理系统DCIM+给出了答案。华为DCIM+利用云化、智能化技术重新定义数据中心管理系统,为数据中心提供了创新的运维管理解决方案。

    随着数据中心规模的空前发展,数据中心运维和运营也面临着严峻的挑战。管理者普遍关心的两大核心问题:如何让运维团队安全管理超大规模数据中心,如何最大化发挥数据中心资源的生产价值。面对挑战和核心问题,华为全新数据中心管理系统DCIM+给出了答案。华为DCIM+利用云化、智能化技术重新定义数据中心管理系统,为数据中心提供了创新的运维管理解决方案。
       
      DCIM当今的一个热点话题
      
      DCIM 全称Data Center Infrastructure Management,数据中心基础设施管理。DCIM是近两年在数据中心管理领域兴起的一个热点话题,旨在采用统一的平台同时管理关键基础设施如UPS、空调以及IT基础架构如服务器,并通过数据的分析和聚合,最大化提升数据中心的运营效率,提高可靠性。
      
      DCIM概念起源于国外,不同的机构对DCIM也有不同的定义,但同一的思想是DCIM工具可以架起一座沟通关键基础设施和IT设备之前的桥梁,从而帮助运营者管理数据中心。
      
      数据中心基础设施管理(DCIM)通过工具监控、管理和控制数据中心所有IT相关设备(例如服务器、存储和交换机)和基础设施相关设备(例如PDU和精密空调)的使用情况以及能耗水平。
      
      数据中心基础设施系统通过持续收集和管理数据中心的资产、资源以及各种设备的运行状态,然后通过分析、整合提炼成有用的数据,从而帮助数据中心管理者管理数据中心并优化性能。
      
            DCIM为IT企业提供重要价值
      
      1.提供对数据中心电力、冷却和物理空间使用的持续重新优化,这可以帮助节省资金用于扩大现有数据中心或构建新的数据中心。
      
      2.整合IT与数据中心设施管理。这有助于拉近IT管理人员和设施管理人员的距离,为他们提供信息和分析,让这两个相互关联的职位重新走到一起。
      
      3.实现更高的能源效率。单从能源成本节约来看,就足以让企业考虑采购DCIM工具,更何况这些工具还提供其他好处,而这些好处可能更难以量化,例如改进工作流程。
      
      4.建模和/或模拟数据中心,让IT管理人员和设施管理人员可以分析“假设”场景。
      
      5.通过显示资源/资产如何关联,加强资源和资产管理。
      
      DCIM面对数据中心运维工作
      
      随着近几年云计算的快速兴起,数据中心日益集中化&大型化,数万机架的超大型数据中心正在陆续出现,导致数据中心的运维管理日益复杂化。因而,DCIM首先要面对数据中心运维工作存在着的人员和设施的问题和解决数据中心运维工作中管理关键基础设施问题。
      
      1、数据中心运维面临的人才队伍动荡
      
      根据2017年CDCC数据中心行业趋势调研结果显示,高达93.7%的运维中心管理受访者表示数据中心运维人才匮乏,不同技能水平人员层次梯队紧缺;而受限于薪资、职业前景等多种因素,人员离职率高,系统运维管理经验难以传承。另据Ponemon研究所的调查报告中的数据统计,2016年数据中心中断事故中,高达22%来自于人为错误;因此,获取足够水平合格、技能纯熟、有责任心的运维人员来支撑数据中心运维工作,成为了当前的一大难题。
      
      2、数据中心运维面临的巡检枯燥重复
      
      日常巡检是数据中心运维工作中重要一环,通过巡检可以尽早发现机房存在的各种隐患。一名运维人员在日复一日、重复枯燥的数百次或上千次抄表工作中,不懈怠、保持警觉性,从中发出某一个隐患,可能并不是人人均可胜任的。如果能够让不胜任的运维人员也能胜任当前工作,则人才匮乏的问题自然就解决了。或者更进一步,借助合适的辅助工具,让有限的人力摆脱重复性、机械性的工作,更加主动管理好数据中心,更好的发挥人的主观能动性。数据中心运维工作中人是最关键的因素,摆在我们面前的问题是运维人员如何在重复枯燥的抄表工作解脱出来,是我们运用DCIM的原始动力所在。
      
      3、数据中心安全运行指标与日俱增
      
      随着数据中心集中化&大型化的趋势发展,目前要求数据中心安全运维的层级分配愈来愈细致。一般来讲,需要保障系统和设备的正常运行;消防系统的完好;具备防水防火、防鼠措施;健全安全出入管理规定;保持机房清洁;建立供应商联系方式;工具和备件管理;事故应急流程和人员安全应急流程制定等。同时,还需要实现系统的连续性管理。这包括,保证所有基础设施设备正常运行;特别要注意发电机状态和自动启动功能、油料储备情况和供应条件等;还要注意可维护性和可快速可修复性检查,包括所有设备的维护和修复。
      
      4、智能化管理,帮助运维人员更高效的工作
      
      智能革命正在到来,将逐步重构现有的数据中心运维方式。如同智能工业机器人的出现,正在将一些劳动密集性产业重新改造成技术、资本密集性产业,解放人员的生产力,重构整个产业的竞争格局。而在数据中心运维中引入智能化技术,借助智能化管理系统来帮助运维人员分析问题、发现问题、解决问题,大幅降低对人员技能素质的要求,减少人工参与环节,从而保障数据中心的长期、可靠运行。例如:在日常巡检中,由智能化管理系统来自动完成各类抄表工作,自动分析与对比数据来发现问题,给出处理建议并通知用户;这样,将大幅减少日常巡检中的重复枯燥的工作,让人员聚焦于有创造力、更擅长的工作上。
       
      华为推出智能微模块3.0及全新数据中心管理系统DCIM+
      
      2017期间,华为首次发布智能微模块3.0及全新数据中心管理系统DCIM+。华为智能微模块3.0是数据中心在产品化、智能化上的创新实践,是从模块化走向智能化的里程碑,标志着数据中心从模块化迈入智能化时代。
      
      DCIM+区别于传统DCIM主要体现在三个方面:第一,通过云化架构实现多数据中心基础设施的统一管理,打通从IT资源到基础设施资源“云化”最后一公里;第二,通过精细化运营实现U位级容量管理和租户维度的运营分析,实现数据中心设施资源的价值最大化;第三,打造设备和管理系统软硬件一体化的智能解决方案,实现从基础监控到智能运维的飞跃。通过智能化的手段逐步减少人工巡检等例行重复工作,将数据中心运营经验、自动化的流程固化到DCIM+内,指导从业者运维数据中心。更希望通过云化、大数据和人工智能的技术方式,在运营层面超越人,成为数据中心运营、投资决策的重要支撑系统。
      
      DCIM不仅是一套软件系统,更应该是集设备智能感知、自动化流程指导和大数据运营决策的智能营维系统,华为已经同业内数家知名厂商展开合作,希望同业界同仁一起,加速数据中心智能化演进,构建智能DCIM+生态圈。

    展开全文
  • 金融业运维体系指南-嘉为蓝鲸

    千次阅读 2022-04-24 15:44:06
    银保监会下发的《关于银行业保险业数字化转型的指导意见》中,提到要建立"前端敏态、后端稳态"的运行模式,同时还需建立能够快速响应需求的敏捷研发运维体系,积极引入研发运维一体化工具等科技能力建设。...

    为加快数字经济建设,推动金融高质量发展,金融行业正大力推进数字化转型。IT运维管理作为企业运营中的环节,在数字化浪潮下,应主动出击,进行数字化能力升级,发挥自己独特的价值。

    银保监会下发的《关于银行业保险业数字化转型的指导意见》中,提到要建立"前端敏态、后端稳态"的运行模式,同时还需建立能够快速响应需求的敏捷研发运维体系,积极引入研发运维一体化工具等科技能力建设。

    本文作者是嘉为科技负责金融行业的顾问赵海兵老师,老师在金融行业深耕钻研数年,主导多个中大型金融单位的运维体系咨询与项目建设,深度调研访谈了多家金融业标杆客户,对于金融行业的运维现状、需求痛点、趋势变化和最佳实践等有深入的理解和洞察。

    赵老师认为,金融行业相对来说,是信息科技实力比较靠前的行业,尤其是银行、保险和证券为代表的金融行业。同时,整个行业的开放度很高,对新科技、新理念的接受度很高,从业人员的素质也很高。因此,金融行业在科技板块(包含运维)的建设,在全国名列前茅。很多新技术或新理论,通常都是先在金融行业开始,然后逐步蔓延到其他行业。

    当然,金融行业在这些年来,也受过许多大大小小的冲击,为此也一直在摸索转型。通过近些年来的研究,我们发现尽管各家金融单位的运维现状不同,采取的措施也不尽相同,但是还是有相当大一部分共性是可以拿出来讨论和参考的。我们今天不聊技术,单从运维体系的较为宏观的角度,去讨论数字化转型浪潮下,金融企业运维体系应该如何去建设和转型。

    01. 为什么要建设智能化敏捷运维体系

    1. 国家政策的要求

    银保监2022《数字化转型的指导意见》里,明确的提及关于运维体系该怎么建设,并从技术、组织维度都下达了具体要求,见下图:

    ▲ 银保监会《指导意见》中提到的具体要求

    其实,已经有一些嗅觉敏锐的银行在悄然落实《指导意见》的内容。比如开始尝试在运维团队内部构建扁平化团队;还有些把研发和运维一同构建技术小组,为某一个产品项目负责;更有甚者,让需求端的项目管理人员和业务管理人员都拉一起,共同为项目和产品的整个生命周期负责。

    2. 权威机构的建议

    Gartner是著名的专业咨询机构,它在解读数字化时解释道:“数字化要改善组织流程、改善人员,组织与事物之间的交互……开发数字技术和支持功能以创建强大的新数字业务模型。”

    国务院发展研究中心在解读数字化时,提到:“打通不同层级与不同行业间的数据壁垒,提高行业整体的运行效率……以数据为关键要素,通过实现企业的生产智能化、管理智慧化…...企业经营智能化、精准化、智慧化则是数字化转型的途径。”

    因此,数字化转型的方针拆解到运维层面,就是用数字化技术改变运维模型的过程,也是要求运维要智能化,要足够敏捷足够快的响应业务需求。

    3. 咨询公司的解读

    一些国际知名的咨询机构,比如麦肯锡、埃森哲、IDC、IBM等,基本都在自己的数字化定义里提及智能化运营。因此,智能化敏捷运营是数字化转型的题中应有之义。

    Gartner还提到,敏捷对于数字化转型路径、开发与交付、运营模式的变革都有着意义。敏捷或者称作“以产品为中心的敏捷交付模式”俨然成为了当下数字化转型的主流。

    咨询机构和Gartner对于敏捷的定义

    由此可见,若企业尚未引入敏捷,那么其将在开发效率上大幅度落后于竞争对手。

    4. 业务维度的需求

    新的业务、新的系统、新的客户、新的模式等诸多挑战导致业务在进行转变,因此IT架构、资源也在变。这也就要求了运维模式寻求转变,以跟上业务的变化。

    ▲ 业务维度的需求分析

    5. 架构维度的需求

    银行理想化的模式基本都是敏态+稳态这两种模式,并且敏态的体量是逐步往上升的。除此之外,传统的模式也在逐步剥离,以支持敏态模式。

    6. 技术因素

    国外也有很多理念在近些年逐步引入国内,基本上过去的运维管理都是ITIL应用运维、ITOM等等。但是现在,很多银行已经陆续在建设的比如APM、持续交付CI/CD、自动化运维、容器、DevOps、AIOps等等。由此可见,技术的迭代日新月异,金融行业也在思考这些技术到底要不要运用,以及该怎么用,从而也促进了数字化转型。

    在这些大的趋势背景下,作为金融行业的一份子,该怎么去做运维的建设,又有哪些挑战呢?经梳理之后,主要分为技术与工具、管理与流程、组织与人员三大方面的挑战。具体如下:

    ▲ 银行运维面临的挑战

    为了跟上数字化时代步伐,银行运维体系需要全面转型与提升,在战略上重视,再从战术上去执行。金融行业不能再期望建一个工具用三年、五年不落伍(稳态),而是工具本身能够满足持续迭代的需求(敏态+稳态)。

    在这种情况下,我们就需要构建以业务系统的保障和运营价值为导向的智能化敏捷运维体系,该体系包括三个方面:

    • 运维工具:构建完备的端到端的自动化ITOM运维工具体系
    • 运维管理:构建符合ITIL4框架、融合式的、高速ITSM运维管理实践
    • 运维组织:以应用为中心的全生命周期综合支撑

    ▲ 银行运维体系所需要的转型与提升

    未来瞬息万变,金融行业想要在竞争激烈的市场环境中存活并稳定下来,需要逐步从传统的以产品为中心,向以客户和业务为中心转变,在此过程中IT运维侧需要共同发力,协同作战。(扫描文末图片二维码,立即申请试用!)

    02. 什么是智能化敏捷运维体系

    首先我们需要了解什么是敏捷,一般性的定义是:敏捷是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。

    ITIL4给出了更详细的定义:即一种框架和技术集合的总称,它们共同使团队和个人能够以协作、优先排序、迭代和增量交付以及时间盒为代表的方式工作。有几种特定的方法或者框架被归类为敏捷,例如Scrum、精益和看板。

    1. 我们在运维层面该如何理解敏捷呢?

    就是从“计划驱动”转向“价值驱动”,从“我”的视角转化为“业务”的视角。具体来说,就是从原来的“我要干什么”,“我想干什么”转为“业务想要我干什么”、“应用系统需要我干什么”,为了保证业务流转的高可靠、低风险、及时性,“我应该干什么”。(扫描文末图片二维码,立即申请试用!)

    敏捷化不是具体的技术,是运维体系建设和运营的方法论,敏捷本身意味着持续迭代、持续丰富、没有尽头。敏捷不仅在DevOps应用广泛,在ITIL也需要使用到敏捷。现在很多单位和企业不断的提到运维开发,提平台化运维模式,正是因为已经意识到过往的买个产品三五年不需要操心的时代一去不复返。

    2. 敏捷化运维模式下的最远目标:AIOps

    智能化的敏捷运维体系,指的是向着智能化不断演进的敏捷的运维体系。智能化敏捷运维,是嘉为蓝鲸认为最适合金融行业未来三到五年的运维模式:以业务和客户为中心,以智能化运维(AIOps)为目标,以敏捷化方法论为建设和运营手段,两者相结合,持续演进与迭代,不断向AIOps演进和靠拢的过程。

    ▲ “智能化敏捷运维”的定义和解释

    参考ITIL4里的定义,企业运维体系有四个要素:组织与人员、信息与技术、价值流与过程、伙伴与供应商。通常来说,关注较多的是前三个。

    围绕建设企业敏捷运维管理体系,拆分下来最上层为价值流与流程,关注以业务运维价值为核心的敏捷运维管理实践;其次是信息与技术,关注以智能化为方向、平台化为支撑的运维技术体系;最底层是组织与人员,关注以用户和业务支撑为中心的敏捷运维组织。

    ▲ 企业敏捷运维管理体系


    银行智能化敏捷运维体系的建设横向是组织与人员,纵向是管理与实践,斜向上是平台与工具,从而实现平台工具、管理实践、组织模式的全面逐步转型。

    敏捷运维体系是一个平台支撑的,场景全覆盖的端到端的自动化工具生态体系,如今已不再是从前那种买一套工具回来三五年都不变的模式了,因为业务、系统、环境都在变,所以体系的横向和纵向都需要具备一定的延展能力,才能满足需求的变化。

    ▲ ITSM体系和ITOM体系

    尽管AIOps是我们希望达到的最终目标,但是就目前而言,AIOps在落地方面还有很大的挑战,因此建议此方向多做些尝试。比如:

    • 在自动化基本建设完成基础上,建议同步开智能化运维试点
    • 选取合适的场景,基于运维大数据分析及智能算法,实现场景的智能分析
    • 之后,逐步以“数据”和“模型”为核心,构建面向业务保障的更加全面的智能化运维体系

    ▲ 由自动化进一步迈向智能化

    在这里需要注意的一点是,过往运维团队往往过于强调运维工具的存在,将非常多的精力和成本投入在运维工具的建设上。这本身没有错,只不过需要从业务价值和运维体系价值出发,看待运维工具,才能更加全面合理。运维工具无论对于业务人员,还是对于领导层,都是无感知的,单单强调运维工具的建设,并不直接带来价值。也就是说运维监控工具本身不直接产生价值,只有工具融入到具体的业务、用户的IT服务管理过程和实践中,才能产生价值。这一点是过往被我们忽略比较多的。

    除了技术和流程,我们还需要考虑组织。敏捷运维体系的组织形式就是以客户为中心,跨职能、端到端,对整体负责的敏捷组织。具体例子比如业务运维敏捷小组打破部门独立工作模式,跨部门组建横向运维敏捷小组,以执行端到端的业务运维保障与运营支撑。

    ▲ 敏捷运维体系的组织形式

    03. 如何建设智能化敏捷运维体系

    综合各个理论标准,结合我们对金融行业的认知,金融行业的运维管理体系可以划分为四个阶段:规范化运维(1.0阶段)、自动化运维(2.0阶段)、敏捷化运维(3.0阶段)和智能化运维(4.0阶段),大多数企业目前都属于规范化运维到自动化运维的过渡阶段。

    第一个阶段,各类工具都已经配备齐全,但是彼此之间相对独立,联动较少。

    第二个阶段,通过ITSM的高速化、自动化的管理,连接外部的ITOM工具,实现业务的可用性与连续性。

    第三个阶段,基本都是服务管理支撑业务的可用性与连续性,工具和数据都在后台。

    第四个阶段,就是通过AI去实现业务流转,取代人的部分判断和决策,实现运维的无人化和智能化。

    数字化转型早不再是纸上谈兵,现已经成为国家的政策要求、监管的要求,同时也是全行业共同努力的方向。因此打造智能化敏捷运维体系,对金融单位和企业都有着深远的意义。

    1. 响应数字化时代号召,实现运维模式的数字化转型

    金融业数字化转型是大势所趋,并不只有业务与开发团队需要进行转型,运维团队也要紧跟时代步伐,进行全方位数字化转型,不致落后。

    2. 对接业务与DevOps,实现端到端的持续交付

    随着DevOp理论和工具的成熟,业务开发团队正在进行从管理到工具链的全方位敏捷转型,运维由于缺乏系统理论指导,在运维体系建设方面是落后的,需要通过技术、管理、组织等多方面建设,迎头赶上。

    3. 实现更加敏捷、优质、高效的业务系统保障与运营

    以客户和业务为中心的敏捷组织,通过同一平台支撑的敏捷ITSM管理实践为中心,充分融合ITOM的自动化工具体系,能够实现更加敏捷、优质和高效的业务系统保障和运营管理。

    4. 为迈向智能化做好全方位的准备

    智能化的前提是全方位的端到端自动化,以及运维管理的敏捷化、线上化和结构化;打造敏捷化运维体系有利于做好智能化运维前夜的全部准备,随时迎接智能化运维时代到来。

    Q&A环节:

    Q1:银行专门成立了数据管理部来管理数据合规和整合工作,运维数据也需要进行数据治理,蓝鲸在这方面有哪些探索和实践?

    A1:您好,感谢提问。数据治理目前已经有较为成熟的方法论和框架体系,运维数据治理也遵循一般的数据治理方法论,从企业的数据发展战略出发,到具体的数据管控、数据管理和数据应用的相关制度落地,构建企业内专有运维数据管理体系。进而通过对应的产品系统和项目建设,实现落地。

    蓝鲸目前也正在将上述理念落地到运维数据的治理方法论和产品思路中,将在合适的时间面市,并与大家进行分享。

    Q2:运维工具体系和领域划分、融合推进,是否有体系化的策略方法?

    A2:如果是运维工具体系的推进,整体上需要上层领导的支持、中下层的执行相配合。具体来说分为三个步骤:

    1. 运维能力和工具蓝图梳理
    2. 基于单位现状,能力差距和工具差距比对。
    3. 实施路径梳理、评审与汇报。

    在具体的实施路径层面,又大体可以分为4个环节:

    1. 运维平台先行。
    2. 基于平台,存量吸收,运维监管控场景覆盖。
    3. 运维管理制度与流程梳理,融合ITOM工具。
    4. 业务系统运维运营场景覆盖与支撑。

    Q3:银行现阶段的监管要求还是传统的职能组织分工要求,怎么对接敏捷运维?

    A3:首先敏捷运维包括敏捷化流程、自动化技术平台和敏捷化组织。这三者之前互相支持,但并没有必然的前后顺序。非敏捷组织情况下,依然可以考虑自动化平台工具的逐步建设,以及传统流程向敏捷流程的逐步转变。其次敏捷组织当然有助于这两者实现,但即便是传统职能模式,并不妨碍前两者的升级,因为对于所有团队来讲,流程优化敏捷、工具自动化的实现,都是会带来好处。

    Q4:敏捷是趋势,但是目前要求还是D/O分离,开发不能碰生产,很多都依赖运维,工作量徒增。有什么折中的方法吗?

    A4:我有以下建议:

    1. 建议先从各个团队监管控工具的自动化开始建设,先解决各个运维团队自己日常运维的重复和低效的问题。
    2. 再考虑团队间的协同以及运维工具的端到端、一体化。这里面有两种情况,一种是不需要管控审核的团队协同场景,可以基于平台直接打通工具间数据和操作执行,实现团队工作自动化串联;另一种是需要管控审核的团队协同场景,需要构建结构化的ITSM平台,来连接团队间工具,并实现审核.
    3. 这两块如果做到八九不离十,基本上日常运维重复工作量会降低很多。则抽出时间来,解决与业务侧、研发侧的协同效率和质量的问题,这就是进一步的事情了。
    展开全文
  • 作者:huashionxu,腾讯 TEG 业务运维专家运维同学作为站在研发团队背后的男人们,一直在担任着举重若轻的角色,而这两年盛行的 Devops、研效变革也直接影响到运维同学岗位职责的...

    39ca1b11b32ffe7001d340a9b88c5ab1.gif

    作者:huashionxu,腾讯 TEG 业务运维专家

    运维同学作为站在研发团队背后的男人们,一直在担任着举重若轻的角色,而这两年盛行的 Devops、研效变革也直接影响到运维同学岗位职责的变化, 腾讯云架平技术运维副总监 huashion 近十年运维领域的自我修养体会,清晰运维人的工作职责定位,文化准则,与大家共同探讨的职业发展,Devops 引发的职位变更等当下乐问热点,本文旨在为所有可能看到的技术运维鹅们带来一些成长的启示。

    世界上第一个运维人名叫 Margaret Hamilton,为什么说她是世界上第一个运维呢?其中是有一段故事的。

    4a93a414f569d1fdd35376dc9c4b6284.png

    Margaret 是在 NASA 工作,一次她带着她的小女儿 Lauren 去工作的地方玩,期间 Lauren 误触了控制台,引发程序崩溃,Margaret 思考在火箭飞行过程中也有可能发生这样的错误,于是她在火箭飞行手册中添加了一段文字,提醒宇航员不要误触发 P01 程序,并给出了恢复手段。Apollo 8 执行飞行任务时,结果真的有人误触发了 P01 程序,幸好有 Margaret 之前给出的恢复手册,最终才化险为夷。

    在今天来看,当时 Margaret 做的工作其实就是在做预案,这跟我们现在运维做的工作是如出一辙的,所以从这个意义上讲,她可以被认为是世界上第一个业务运维。

    当时她还说了这样一段话,“无论对一个软件系统运行原理掌握得多么透彻,也不能阻止人犯意外错误。”这其实就是运维的思想,也是我们每天在干的事情。

    一、运维到底是干什么的?

    ab7646c0ac9887aa5aec680ceb865d5a.png

    很多人认为运维应该是在机房搬服务器,插拔网线,调试网络,或者修电脑的。但我们自己觉得运维应该是个比较“高雅”的职业,每天状态是在办公室,泡杯茶或咖啡,面对电脑处理着工作....但实际上呢,其实还是挺苦的,很多运维同事都是救火的状态,觉得特像消防员,每天都是在面对各种线上问题,半夜还要值告警,特别辛苦同时压力也会很大。

    1、运维的工作分类

    617c3a1477f18324ccd152b84532588e.png

    运维这个职业有很多工种,比如说我自己是做业务运维,主要是面向业务的;还有系统运维,比如负责网络,操作系统的、底层 IaaS 的等等;还有一类是数据库 DBA,是专门负责数据库;还有专门负责安全的安全运维;还有运维开发,Devops(AIOps)负责开发运维工具和平台;还有像我们 8000 的小伙伴,做IT运维。

    因为现在大部分的基础设施都云化了,如果按照云的维度来看,又可以分为 SaaS、PaaS 和 IaaS 运维。

    2、运维的工作职责

    ecd52a3ae1fde6ff9b780812803ae32b.png

    运维的工作职责和定位通常是:第一个定位 质量守门人,运维最核心的 OKR 或 KPI 就是围绕质量,负责所有线上的问题;

    第二个定位是效率提升者,运维需要对日常的一些重复工作去开发各种各样的工具,提升整体运维效率,这样才能更好的去驱动质量的提升;

    第三个定位是口碑维护者,很多运维同学都是要接触业务,不管是负责内部自研业务还是外部云客户,都需要深入业务做好服务,在 TEG 很多同事都承担了这样的职责,这就是左边的圈。

    同时我们日常开展工作锁围绕的三个生命周期(右边的圆圈):

    第一个故障生命周期,故障生命周期就是从一个故障最开始的发生,到发现,到定位,到分析,到最后恢复;

    第二个应用生命周期,所有线上跑的应用 APP,从最开始的发布评审,到发布上线,到监控,包括做资源,后面预案,都是围绕应用生命周期;

    第三个资源生命周期,资源生命周期和应用生命周期还是有些区别。因为运维还管了很多设备,包括硬件设备,IT,实例资源,那就要去做资源生命周期的相关工作,包括资源的申请、报备......所以运维的职责大致就可以用这两个圈来概括。

    3、运维的工作内容

    0efcb10b6735a808328ada938d6b897e.png

    具体工作基本围绕质量、成本、效率、安全,大家每年在写 OKR 或做规划都是围绕这几方面来做,质量提升、性能优化、成本优化和安全优等等。

    4、运维文化

    运维跟研发,或者研究等其他岗位是有些差别,我大致总结了几点。

    4.1 故障文化
    f7023ca81782b1d47082a1df7f173ddb.png

    第一种 故障文化,江湖人称运维叫“背锅侠”,这大概就是我们运维人的常态。“不在复盘,就在去复盘的路上。” 特别是做云的小伙伴,基本上每天都在复盘,只要线上出了问题,先录单,录完后,QA 就会来说“我们复盘吧”,然而这个问题还没有复盘完,又出现新问题了,复盘完了之后又继续……所以基本就是每天“不在复盘就在复盘的路上”。

    大家都说“没有经历过大的故障的运维,不能称得上是一个好运维”。相信每个运维人都会经历过很多的故障,但对于运维岗位,我们在做问题复盘时,是真正意义上的“对事不对人”,这里不会去计较为什么是这个人犯的错、出的问题、写 bug,重要的是为什么会出这个问题,出问题后能否更快发现和恢复,或从流程机制上保证下次不再同样犯错,所以在运维的文化里面重要的一点。运维都够做到真正的对事不对人,关注问题和关注事情本身。

    同时重要的是,大家是在故障中成长,在复盘中变强。这里给大家讲 3 个让我印象非常深刻的例子

    第一个例子是发生在我自己身上的,在上家公司大概入职 2 年多的时候,有一天接到一个磁盘告警要去清理磁盘,然后我马上进入服务器根目录下敲了行代码“rm -rf *”。过了三秒钟自己反应过来,刚刚好像是在根目录底下运行下删除,当时是立马按 Ctrl C 恢复,但其实已经删了一些内容。但很诡异的是当时没有出现任何问题,但我依然很害怕,就赶紧给模块的研发打电话,说把根目录给删了,他也慌了马上与我一起复盘;在复盘的时我们发现没出问题,因为当时很多的程序直接加载在内存中运行,所以没有影响线上服务,这个也是不幸中的万幸......记得当时公司有个叫鸡翅文化,就是如果你犯小错误就请所有人吃鸡翅,我当时是请研发同学们吃鸡翅,这是我人生第一次也是唯一一次请研发吃鸡翅。这次事情让我记忆深刻后来我把这个案例写到了中心的新人培训材料分享出去,想不到后来真的有同学去试了一遍,把仓库删掉了:( 这真是一个很常见、容易犯的错误。

    第二个故障是我入职时导师讲的,有个同学半夜接到电话说某一批机器的分区要满了,那个同学动作很快马上写了一个脚本开始批量删除,结果不小心把历史网页库的 1/3 全部删除了。因为很多历史网页实际上现在已经没了(原站已经关停了),所以他这次操作基本上把中国互联网过去十年前 1/3 网页干掉了,但当时 leader 跟我说这个同学还在公司,而且发展还不错已经是经理了。这个例子让我震撼的是,虽然运维做错删库了(任何一个人都有可能犯错误),但只要不是故意不管是主观还是客观原因,至少大家对于运维都不会去针对人,还是聚焦事情本身。

    第三个是 2018 年我遇到,印象很深刻是这个故障发生后,我去北京做行业认证,刚好遇到国家部委工信部的同事来详细地了解情况,后来工信部的同事把这个故障涉及的流程规范写进行业认证的规范中。那时我在想,由于一个问题出现竟然可以影响或者改变行业的一些东西。

    所以总结来说,故障文化就是运维需要认真地去针对每一次故障、事情和问题本身、以及针对性的解决方案和故障预防或规避流程。

    4.2 线上文化
    9254a1791cf05e58e0a761159846ccd4.png

    第二个是 线上文化。通常来说,运维对线上是最敏感的,比如最近在做春保,不知道大家有没有去好好拜拜服务器(玩笑),这里不得不提大家常讲的一个词叫敬畏心,亦或是对线上的敬畏心。

    敬畏心到底是什么?我尝试做下总结:

    不轻易去改变线上当前稳定的运行状态;如果要去改变,一定要多次验证,并且是可逆的;

    因为它现在运行得好好的不动就不会出问题,一动就有可能会出问题,所以你去真正改变线上稳定运行状态的时候,要想如果我改变了之后可能会有问题,能不能再恢复到原来状态。原来我理解敬畏心很抽象,但落到日常的具体工作中,这其实就是运维具备的基本常识(有些研发在出问题的时候可能第一反应是 debug 或者 fix,而运维会优先止损),所以这里也是我认为运维这个职业跟大家很不一样的地方,比如在做发布变更的时候,要有灰度意识,所有不经过灰度直接发布是不能接受的,稳定性更不用说了,线上的稳定是运维的底线或者是生命,所以运维的线上文化是很重要的。

    5、运维准则

    f4cc001bf77bc247df78ccb7e8bb9b23.png
    5.1 墨菲定律

    下面我想跟大家分享下准则,每个行业都有自己的祖师爷,逢年过节要去拜一拜。运维这行应该拜谁(祖师爷)?我上面列了三张图,第一个是墨菲。因为我以为做运维一定要相信墨菲定律。什么是墨菲定律?其实墨菲定律本身是一个心理效应。大概讲的是:

    ● 首先,任何事情都没有你表面看上去那么简单。

    ● 第二,所有的事情基本上都会比你预估的时间要长。

    ● 第三,你以为会出错的终归会出错。

    ● 第四,如果你担心某件事情发生,它就一定会发生。

    经常我们关注的可能是第三点和第四点,就是小概率事情一定会发生。所以为什么运维要信墨菲定律?其实逻辑很简单,本身我们职业的特殊性,就决定一个应用程序或者一个配置真正到线上生效,我们是最后一道屏障。

    我记得很清楚,有时研发同学在跟我们复盘时,经常说这个 bug 是一个小概率事件,它触发的场景非常有限,但是这不能放到运维身上来,因为运维是线上的最后一道屏障,兜底的,如果从我们这边露出小概率事件,有可能真的会导致故障。所以作为运维一定不能容忍所谓的小概率事件,只要这里有个隐患,我就不能偷个懒,就不要想着故障可能不会出现;要想着如果有隐患不解决它就一定会出问题。不要轻易的把一些所谓的小概率事件漏掉,这是墨菲定律。

    5.2 恩法则

    第二个 是个德国工程师的海恩法则,是个关于飞机飞行安全的故事,德国人非常严谨,海恩在经过研究发现每一起严重的飞行安全事故,背后一定有 29 起轻微事故,以及 300 起未遂先兆,以及 1000 起事故隐患。量化的数字可能是经过科学分析的,但实际上他想强调两点:首先事故发生一定是量变引起质变的,是一个积累的过程;第二是再好的技术、再完美的规章在操作层面,也无法替操作人的素质。

    总结海恩法则,在日常工作中,发现一个故障,再去做复盘,你会发现是因为他前面每一层都在出问题,一点一点,有很多先兆。

    5.3 灰犀牛理论

    第三个是灰犀牛理论,这个理论实际上最早用于金融界,但是你会发现,不管是造飞机,心理学,金融界,跟我们工作都很有关系。灰犀牛理论跟海恩法则有些类似。黑天鹅事件大家应该都知道,黑天鹅其实是一种偶发性、不可预见的,之所以叫黑天鹅,就是因为它突然出现,无法预防。但是灰犀牛实际上是一个你能够看见、显而易见、很大的一个危机。

    所谓的灰犀牛事件,出现时不是随机突发的,前面有一系列的警示与告知,最后才慢慢变成一个黑天鹅事件。所谓黑天鹅事件,或者故障,是想告诉大家,在出现这些迹象和这些警示的时候,我们不应该掉以轻心。有时你会偷懒,会得过且过,但实际上前面有很多地方不应该去轻视它,要去解决它。跟海恩法则会有一些类似。大家以后逢年过节,或者重大保障之前,除了拜服务器也可以拜一拜这三位,千万不要出问题。

    这些所谓的原则准则,希望能够变成大家的职业习惯,变成潜意识去主动思考问题。首先不要相信小概率事件,该发生的一定会发生。第二,要去重视一些潜在的东西,出现隐患时要及时解决,不要让它变成真正的一个故障。

    6、运维人的特质

    运维人跟其他人除了在工作职责上有区别之外,在特质或者素质上有什么不一样?我总结出 2 个特质,也许可以帮助大家更好的去工作。

    6.1 第一个特质,大心脏
    a08a73966b11b5606b6294d4b83c14c3.png

    鲸鱼是地球上最大的哺乳动物。鲸鱼的心脏是世界上最大的,据说有 800 公斤。而作为运维人来说,我认为也需要有这样强大心脏。

    首先是线上操作,很多时候,即使你知道接下来这个操作非常重要,操作下去可能会出重大的问题,比如说把某一个服务重启,但如果在前期做好评估,预案也已想清楚,前面所有都做了,就应该有自信,线上操作胆大心细。

    第二个,当真的出问题了所有人都很慌乱时,在整个产品或团队中唯一不能够慌乱的那个人就是运维。因为本身你更清楚监控更清楚预案,清楚如何操作,如果连你的手都在抖,都在害怕,那这个问题大概率没人能够靠得住。

    第三,复盘和故障是家常便饭,每天都在出故障,有时大家会常常因为某些故障很懊恼很纠结,但是我觉得大家要习惯,我们应该越挫越勇。 出问题没有关系,通过流程和工具把这些问题彻底解决掉,不用太纠结;对于已经入行和即将入行的,或者未来大家想继续发展的,我觉得这一点特质非常重要。

    6.2 第二个特质,强迫症

    a251e459d8dec66f8091576fa7268078.png

    第二和重要特质,强迫症。 为什么要有强迫症?有时看到一些隐患或者不好的操作习惯,甚至一些不好的流程等,这时我们不应该容忍,特别是有些问题或隐患可能涉及到线上,更不可以,应该立刻解决。第二个,运维工作本身挺繁琐的,包括有很多重复劳动,第一遍第二遍,会做很多遍。对这些 Dirty work 我们也不能容忍,应该想法做工作做平台去提升效率。第三个,如果大家做出来的这些流程,没有人遵守,或者因为各种各样的特殊流程去跳过某一个的,这个流程本身就没什么存在意义,所以在执行的时就应该是一步都不能少。

    我希望大家在工作时该有这样的强迫症,对线上负责,去消灭一些问题,提升效率;做流程时也严格执行,流程一步都不能少。

    二、技术成长和个人成长

    接下来,我分享下运维人的技术和个人成长部分,因为运维人员本身工作很琐碎,所以大家就更关心里面有没有成长,每天都在发变更,日复一日,年复一年,会非常焦虑。

    1、核心竞争力

    3dad0e88f1c3b8a32b03f1c41f9e60a2.png

    运维人的核心竞争力是什么,所谓核心竞争力是不可替代性,应该怎样去做?我认为:

    第一个 核心竞争力是对操作系统掌握。 原来最早做运维的人就是所谓的古典派,他们对操作系统是非常深入的。我们现在很多应用和服务还是跑在 Linux 或者 unix 操作系统上,所以对应出现问题应该怎么去排查,性能怎么去优化,监控怎么去做,而这些都是需要对操作系统原理和架构清楚的,所以操作系统是很核心很基础的。

    第二个 核心竞争力是对业务和架构的深入掌握。 运维会负责不同产品,它们之间的区别到底是什么,我觉得就是对所负责的业务和架构的深入理解。比如我是做存储的,对整个存储的架构,整个链路,底层的理解,以及关联的存储网络、存储硬件的了解和掌握,是你不可替代的部分。这是未来你再去找工作,大家最看重的东西。因为只有你深入的去做这个业务,做了很多年,你脑子里有很多东西是别人不知道的或者是别人容易忽略的。如果说有一个新的业务,也要做这一块的业务,就非常需要这样的人,不管是运维体系,还是丰富的线上运维经验。

    到底怎么深入,大致可以用这样一个路径。比如一个开源软件,开始做肯定从网上找一些资料部署起来,稍微改一改,可以运行起来其实这才仅仅是第一层;然后你发现这个性能好像上不去,那就去研究哪些配置可以深入优化下、适配业务,所以第二个层次是能够做些配置的优化;第三个层次,是发现有一些功能没有,比如可能会基于它的源码做一些插件,去实现它的更多功能;再往下深入,就是让自己要去重新造跟这个一样的东西(原来我们也干过这个事情,比如说重新写一个做接入程序,有没有这样的能力能够把他包起来)所以它是一层一层往后去深入的,大家可以看下到底现在在哪一层,就可以很清晰地知道应该再往哪一层去深入。

    第三个,方法论。 用我个人的经验来说,我原来一直做存储,然后 19 年 leader 让我去负责数据库,当时我并没有数据库的背景,基本上就是知道最基础的操作而已,这种水平让我就很虚。但后来去做了我发现很多事情其实是差不多的。

    首先 数据库业务也要关注故障生命周期,都要做监控、定位、预案恢复;当然也有不一样的地方,原来存储我们巡检的是硬问题、存储节点状态,数据库巡检是主从状态(是不是断开了,是不是延迟),这就是业务差异化的内容;所以我就把原来做存储的一些思路,拿来去做数据库,除可能有一些上层的业务不太了解,其他还是能够复用的。专业和业务层面也不用当心,会有专门的同学来帮助我们学习。

    所以,当你做一个产品很久之后,有没有去总结这个产品,比如应该怎样去运维,如果给你一个新的产品,你能不能把你原来的经验抽象出并且把它复制到一个新的产品,把这个产品做好。比如存储做好了,可以经验复制到数据库,比如再去做 CDN 能不能做,只有你不停总结去提升,然后把它变成方法论,那你本身的能力就是在提高的,而且你的 scope 也变得越来越大,所以我觉得方法论其实是挺重要,特别是方法论本身的迁移的能力。

    总结下,运维的核心,就是这三个(方法论、业务和架构、操作系统)。

    2、运维人的技术栈

    6a5ad857e9ae8695462c5e855bce5098.png

    运维的技术栈比较杂比较广,我总结了一些,可以参考左边的这张图。

    右边这个图很好,可以用来做 Linux 性能监测或者调优,Linux的体系架构是什么样,每一层应该去用什么工具去看,对应什么样的指标(这个图在网上找就能找到)。

    前面我在讲基础的核心竞争力的时,已说道对 linux 的操作的掌握是基础。技术栈也是一样,操作系统一定是技术基础中的基础,然后涉及四大方向:计算、网络、存储、数据库。

    如果你做业务运维偏向计算业务,那计算已经做得很厉害后,你还可以去拓展去做网络往深处去扩展,技术是不可能一成不变的,所以除了把基础打好了之外,可以往其他的方向去做扩展和补充。

    3、技术成长

    技术成长也是很多同事在聊的话题,比如最近状态不好,每天都在这干一些重复的事情,也不知道有没有前途,也不知道技术该怎么发展。但其实关于技术成长有个很好的实践,就是公司 P 族的技术运营通道,通道给出了很详细的能力模型系统,分了很多的子通道,每个都有一套完整的模型和能立项。

    a41cb4801ac95fb1fa2524402f3894c0.png

    如果你不知道自己到底应该怎样规划技术成长或者技术路线中,可以参考技术运营通道的描述,其实就是是两个维度,第一个是专业知识,是横向的维度,第二是级别深度, 是纵向的深度。

    215e93a18bdcb94303ebcf4bc5a21cc7.png

    从一个处理现网问题的运维工程师在不同级别的要求是不同的,可以看到对应 8 级或者 10 级的要求是完全不一样的技能

    当然还有另一个最简单的方式,大家可以关注一下其他大公司的招聘要求,里面会很清楚的定义这个岗位和级别需要什么样的技术。

    1ec9b45ded767de7a7d14fa5c005e7bf.png

    接下来是运维技术的发展和运维体系。运维技术的发展,大致经历了标准化、自动化、数据化、智能化这几个阶段,不同公司不同产品所处的阶段不尽相同。大家也可以对比下自己当前负责的产品处在哪个阶段。这里我总结了行业内不同公司的运维体系,从中可以看出不同公司的运维体系还是不太一样,但其实很难去说哪个运维体系先进。因为不同公司业务、所处的阶段不同,那么他所需要的运维体系可能就不一样。对于行业的趋势和最新的技术,大家还是需要保持学习和敏感度。

    4、转型

    这个也是我想重点提的,最近很多同学很焦虑这个问题。首先说 SRE,PCG 有很多组织都已经改了,包括职责也有对应的转变。

    58522892412d7446d5b22e381909f875.png

    到底什么是 SRE? 我的理解很简单:SRE 就是当你让一个软件工程师来带运维团队的产物。Google 的 VP Benjamin 在 2003 年加入谷歌时,当时 Boss 给他的任务是让他组建一个由 7 名工程师组成的生产团队(Production Team)。要知道,在这之前他一直都是个写代码的程序猿!所以他只能按照我自己对运维的理解和想法和组建和带领这个团队,这个团队就成了今天 Google 的 SRE 团队,这个团队也一直坚守着由一位终生程序猿设定的初心。

    SRE 团队中的角色分为两类,其中 50%-60%的成员就是 Google 的软件工程师;其余 40%-50%的成员他们本身符合 85%-99% Google 软件工程师的招聘标准,但他们具备一些软件工程师没有的技能,例如 Unix 系统、网络(1 层-3 层)方面的专家,这些技能对 SRE 来说是非常有用的。所有的 SREer 都要求有能力和意识通过开发软件系统来解决负责问题。在 SRE 内部,通过跟踪调研以上两类成员的职业发展轨迹,我们发现并没有什么不同;事实上,不同背景的 SREer 让我们的团队产出了智能、高质量的运维系统。转型——不会开发的运维不是好产品经理。

    第二个是 DevOps。 DevOps 我们团队涉及不多,现在的团队主要是做存储,基本上没有转型 DevOps,但实际上现在整个公司包括 TEG,大家都在往这条路上去走,所以这里我浅谈下自己的理解和看法。

    我理解 DevOps 更多是一种能力模型。SRE,实际上是对 DevOps 的一个最佳实践。

    SRE 更多针对 OKR,DevOps 我觉得更多像一个文化,或者是一种模型。他强调开发运维一体化,为什么要强调一体化?大家知道,在软件工程最有效率的一种组织架构,就是一个人从写代码、测试、开发、运维全部做完,因为他没有沟通,也不需要沟通。我们现在很多团队是 DO 分离的,DO 分离有个最大的问题,就是两个人天天吵架,我们 kpi 也不一样,会有各种各样的冲突,有很多其他成本,但是如果一个人很厉害全都搞定了那就非常有效率,所以 DevOps 最朴素的想法就是,围绕效率把开发和运维一体化。我认为 DevOps 这件事情更多是一种文化,衍生出来一些方法,组织形态,以及一些工具。

    第三点,更高大上的一个词叫 AIOps。 这个词实际上提了好多年,但现在大家看你身边真的有很多 AIOps 吗?其实没有。

    首先 AIOps,不管是岗位或本身,它是有专业门槛。因为大家做传统运维出身,可以搞定 Linux,写脚本。但如果想往 AIOps 发展,或想知道 AIOps 到底干什么,或需要具备什么能力,我以为大致有 3 点:

    第一点,建模能力。 我们遇到的问题都是运维问题。比如快速恢复怎么监控怎么去管资源,但是 AIOps 每天是做的是数学问题(可能是一个分类问题或聚类问题)所以你要有能力能够把运维问题,抽象建模成数学问题,这是最基础的。如果你都不知道怎么把运维问题变成个数学问题,光会算法也不行。有很多同学原来在本科或者是研究生是学算法相关的,但他不懂运维,我们很懂运维但我们数学不太好,所以这里还是有一些专业门槛。

    第二点,数据。 现在很多算法最基础是要有数据,有些时候需要做训练,所以有时需要的是有标注的数据。如果你不知道怎么建模,也不知道用什么方法,你先把这些数据全部规划好存储起来,并且能够做好标注,那未来想拿这个数据做一些事情,你是有基础的。反过来如果你有算法,却发现真的要去做很多事情的时候没有数据,这是很致命的,所以我觉得数据对于 AIOps 来说也是很重要的。

    第三点,算法。算法现在的平台化和工具化做得非常好,有各种各样的平台,想要什么算法,只要把数据往里面一丢,自己勾一下就行,再做一下调参,这个事情大概就搞定了。如果具体去做算法,或者说研究算法,那可能会比较难,但如果仅仅想用算法,我觉得现在其实门槛没有那么高,各种各样的平台和机器学习相关的一些插件已经很成熟了,所以算法其实还好。所以 AIOps 是的专业门槛的,大概需要把建模能力,数据能力把全部给做起来。

    三、运维最终的出路是什么?

    最后,也是现场一位同学问我说,运维最终出路是什么?

    我的理解是,首先是这个问题在于说大家把自己的角色想得太局限了,总是认为自己是一个运维工程师,就应该天天去看监控、变更,故障处理等等。但实际上我觉得运维最终归宿一定是业务。举个很简单的例子。

    第一个例子,原来在上家公司的时候,运维每天都要做告警轮值,这件事情不仅在运营团队,在研发团队,在各种团队都有需求,所以我们当时就把这个事情变成了一个平台,先给公司内部给所有的人用,后来把这个平台变成一个产品卖给其他的公司。因为每一个公司都要做轮值,然后再后来业界出现了个公司 PageDuty,他其实就是把运维的这件事情产品化了,去卖钱。

    第二个例子,跟我专业相关的,我是做云盘 CBS,CBS 有不同的规格,有低性能、中性能、高性能。那我们做了很多迁移和调度的事情,比如说用户反馈性能有瓶颈,我可以把他从低性能迁移到高性能上面去,用户就没有问题了。如果我作为一个用户,本身业务是有峰谷的,如果买的高性能云盘,那就一直要按照高性能云盘付费。但晚上如果低峰期,那能不能在晚上把它降成低性能。第二天早上业务高峰期之前,再通过无缝迁移,继续迁移到高性能上去。在运维来看它其实就是一个迁移的工具,但是实际上如果能把它变成一个产品,可能就要一个自身的预判能力;对于用户是非常喜闻乐见,因为原来的成本是一条这样的曲线,通过我们的产品之后,可以变成另一条曲线,能够为用户节约成本。

    所以,大家不要把自己想得局限,我们应该想怎么样把我们的运维能力、工具平台,往整个产品的主路径上去输出,产生更多的价值。站在更高的角度去想,能不能给产品增加的更多价值。

    最后一句话,不会开发的运维不是好的产品经理。现在对运维的要求越来越高,你除了会运维之外,还要会开发,像 DevOps,结合业务,还是需要有很多的产品思维和产品能力,这样才能够不断拓宽你的职业道路!

    展开全文
  • 如果系统需求变动不大,这种模式基本可以满足。但当遇到问题的时候,解决问题的时效性、准确性就没那么高,牵扯到很多因素就不一一列举了。问题滞后带来的潜在影响很大,容易引起现场用户不满及消极抵抗情绪,管理层...
  • 公众号回复:干货,领取价值58元/套IT管理体系文档公众号回复:ITIL教材,领取最新ITIL4中文教材正文某银行省级数据中心 IT 运维服务体系建设,应包含运维服务制度、流程、组织、队伍...
  • 运维

    2017-12-24 20:22:08
    运维,这里指互联网运维,通常属于技术部门,与研发、测试、系统管理同为互联网产品技术支撑的4大部门,这个划分在国内和国外以及大小公司间都会多少有一些不同。 一个互联网产品的生成一般经历的过程是:产品经理...
  • IT运维服务体系建设思路

    万次阅读 多人点赞 2019-02-13 13:38:44
    数据中心IT运维服务体系建设,应包含运维服务制度、流程、组织、队伍、技术和对象等方面的内容,整合运维服务资源,规范运维行为,确保服务质效,形成统一管理、集约高效的一体化运维体系,从而中国人民银行省级数据...
  • Linux运维工程师岗位前景及学习路线 目录: Linux运维工程师岗位前景及学习路线... 1 讲师:老男孩自我介绍... 1 1.1 什么是Linux?... 1 1.2 Linux系统发展前景?... 2 1.3 什么是Linux运维?... 3 1.3.1 ...
  • 运维体系研究

    2019-09-18 05:31:19
    新型运维和传统运维分界截然不同,本文将不过多的对新型运维和传统运维说明以基本运维展开对运维体系的深入研究。运维,这里指互联网运维,通常属于技术部门,与研发、测试、系统管理同为互联网产品技术支撑的4大...
  • 1.3 职业定义 从事与人工智能相关算法、深度学习等多种技术的分析、研究、开发,并对 人工智能系统进行设计、优化、运维、管理和应用的工程技术人员。 1.4 专业技术等级 本职业共设三个等级,分别为初级、中级、...
  • 面向失败设计 渐进式设计 优缺点如下 优点: 模块的强边界 独立部署 技术选型的多样性 缺点: 分布式带来编程复杂度,远程调用的消耗 舍弃强一致性,实现最终一致性 操作复杂性要求有一个成熟的运维团队或者运维基础...
  • 为了确保系统可靠、高效运行,为业务使用人员提供更高、更快的服务质量,需要建设一套一体化智能运维大数据管理平台,对机房中动力环境、IT基础设施、IT硬件设备、IT基础软件等进行全面监控、信息统计与分析,实现...
  • 点击上方“方志朋”,选择“设为星标”回复”666“获取新整理的面试资料无论是系统运维,还是应用运维,均可分为“纯手工”—> “脚本化”—> “自动化”—>“智能化”几个阶...
  • 操作复杂性要求有一个成熟的运维团队或者运维基础设施 二、为什么要采用微服务 是否选择微服务取决于你要设计的系统的复杂度。微服务是用来把控复杂系统的,但是随之而来的就是引入了微服务本身的复杂度。需要...
  • 了解运维工作与分类

    万次阅读 多人点赞 2018-06-30 12:40:27
    运维运维,这里指互联网运维,通常属于技术部门,与研发、测试、系统管理同为互联网产品技术支撑的4大部门,这个划分在国内和国外以及大小公司间都会多少有一些不同。一个互联网产品的生成一般经历的过程是:产品...
  • 2019.9月,我裸辞了。 很多人都说最近大环境不好,不要裸辞...这里大致分享一下,对于同样的运维人来做一个参考,在自己不同的阶段应该怎么去选择自己的路。以下所有皆为个人见解,保留意见。 首先,在运维的领域...
  • 背景介绍: ...同时,为保障1+X职业技能等级标准工作的顺利推进,华为联合高校教师共同编纂《网络系统建设与运维》(初级、中级、高级)和《智能计算平台应用开发》(初级、中级、高级)系列教材。
  • 为什么开发人员都看不起运维工程师?

    千次阅读 多人点赞 2021-02-09 19:07:45
    最近看到一个新闻,一名网络工程师跟运维工程师聊天,最后因为月薪问题吵起来了,网络工程师骂运维工程师就是个low逼,拿着互联网人的工资,干着网管的活,场景非常难看。 其实在我看来,严格意义讲这两个岗位之间...
  • 网络工程师和网络运维工程师是一样的,其实二者有着很大的区别,下面给大家介绍一下正文: 一、工作内容不同 1、网络工程师 1)负责机房内的网络联接及网络间的系统配置。 2)负责系统网络的拓扑图的建立和完善,...
  • 有人说在云计算工程领域,最难的部分是运维,因为管100台、1万台或是100万台机器,是完全不同的概念,你想机器少可以人管,机器多了还能靠人么,当然不能了。再则,运维系统不属于功能性的东西,常常因为用户看不见...
  • Linux运维工程师岗位前景及学习路线

    千次阅读 2019-12-14 21:02:18
    Linux运维工程师岗位前景及学习路线 1.1什么是Linux? 大家日常使用电脑听歌、打游戏娱乐或处理日常工作时,接触到最多的就是Windows操作系统,电脑如果不安装Windows系统是无法进行娱乐和工作的,所有的软件程序...
  • 运维运维工程师的相关知识-科普 运维,这里指互联网运维,通常属于技术部门,与研发、测试、系统管理同为互联网产品技术支撑的4大部门,这个划分在国内和国外以及大小公司间都会多少有一些不同。 一个互联网产品...
  • 更多专业文档请访问 www.itilzj.comIT运维?IT运营?都是 IT Operations,有什么区别?IT运维管理?IT运营管理?都是 ITOM,有什么区别?一字之差,只是翻译...
  • 过于集中化 对DBA要求 需要综合使用工具的能力 需要专业的调优能力 云数据库与传统数据库比较 DTC:云数据库服务运维体系需要注意哪些问题? A:云数据库服务,是服务就会出问题,必须转换的思路(数据库单服务实体...
  • 咨询QQ:咨询:1035240118...2、Linux基础知识、基本命令、获得使用帮助及文件系统组织结构等; 3、Linux用户、组及权限的基础及相关高级话题,详细讲解useradd/userdel/chmod/chown/usermod/chage/umask等相关命令...
  • Linux运维十年面试总结 一、有文件 file1 1、查询 file1 里面空行的所在行号 awk ‘{if(KaTeX parse error: Expected group after '^' at position 4: 0~/^̲/)print NR}’ file or grep -n ^$ file |awk ‘BEGIN{FS...
  • 智能化”几个阶段,其中自动化阶段,主要是将一些重复性人工操作和运维经验封装为程序或脚本,一方面避免重复性操作及风险,另一方面提高执行效率。在自动化运维的转变过程中,经常使用的可能就是shell脚本了,...
  • 云数据库离不开云计算,云数据库是建立在虚拟机上为基础的,带有云计算的特征、共享、弹性、智能。传统的数据库拿Oracle来讲,本身是比较重的,安装部署都是个重型的工程。云数据库轻巧,有更多解决方案,能组建更多...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,557
精华内容 622
关键字:

智能运维基本素质要求