首先声明自己不是ITIL方面的专家,特别是具体的规范细节,后面论述如有不当,请指正。但我为什么会提起它?主要是因为它和运维(IT服务管理)相关性太大了。早起的运维完全就是以ITIL来蓝本构建的,在当时公司中还有ITIL学习小组/实践活动、ITIL的外部顾问培训等等。后来在YY的时候,当时实践CMDB、事件管理的时候,也是参照了其具体的规范和要求。我建议大家在讲ITIL的时候,一定要把ITSMF授权荷兰人Jan Van Bon写的两本书都看一下,可以迅速扫盲,避免对ITIL的耍流氓式理解。
1989年,第一版ITIL书籍(ITIL v1)问世,但在当时并没有受到太多关注;
在文章之前,我想花点文字来说一下D/O分离,在工作过的几家公司运维,都曾经强调过D/O分离。个人承认在早期,比如说运维团队成立初期,D和O此时没有职责界定,这个是非常必要的,它能快速厘清各自的工作内容,然而随着团队逐渐规范,甚至在向ITIL过渡的过程中,过分强调D/O分离,其实带来了很多问题,典型就是相互推诿和运维团队的边缘化。相互推诿是因为在工作中很难把所有的事务分清,你做也可以,我做也可以,那谁来主动说我做呢?运维团队的边缘化是D会逐渐把琐碎的事务转移给O,O会逐渐陷入到这类频繁的事务中,无法找到自己的存在价值。因此我一直对D/O持否定态度的。
ITIL 4自19年正式对外发布,至今已经有2年了,目前已经建立了较为完整的框架体系。运维领域因为ITIL 4的发布带来较大改变,因此本次直播我们将围绕ITIL 4出现前后的运维侧的改变为主题进行讲述,内容分三大部分:ITIL 4说了什么、ITIL 3与ITIL 4的区别对比、我们应该如何提升IT服务管理水平。
在上一篇文章《你所不知道的CMDB | CMDB起源与发展》中,我们谈到,CMDB的概念起源于1999年,但是在近几年才声名鹊起。本篇文章,我们将继续聊下CMDB的两类应用场景。
关于IT服务能力的介绍,本期标题中主动式、可量化、构建IT运营服务三个关键词概括了我对IT服务能力的理解,其中IT运营服务在上一篇《IT运营转型中的ITOM》作了一些分析,本篇从ITIL、ISO20000、ITSS方法论对服务做补充。另外,IT服务能力主要以ITSM方式提供IT服务,关于ITSM的实现方式在之前关于servicenow的文档中也作了介绍,本篇不介绍在ITSM上的服务具体实现,而是从主动式、可量化两个角度进行扩展。
ITSM已死,“DevOps+云”当立——尽管这种非此即彼的极端论调,已伴随近几年的开发与运维实践慢慢隐退,但处于守势的ITSM一直在质疑和争议中艰难前行。
ITIL(Information Technology Infrastructure Library)是全球最广泛使用的 IT 服务管理方法,旨在帮助组织充分利用其技术基础设施和云服务来实现增长和转型。优化IT运维,作为企业运营的关键环节,对于提升效率、增强IT与业务目标的一致性至关重要,进而深刻影响企业的经营发展。因此,积极探索并实践高效的运维策略,对于企业的长远发展具有重大意义。
智能化敏捷运维体系这个概念,它主要分为两个层面:敏捷、智能化。嘉为是在国内最早一批提出智能化敏捷运维的公司,相信大家在之前也听过很多运维相关的方法论,比如说自动化运维、智能化运维、AIOps、数据化运维、SRE、ITIL4等等。而智能化敏捷运维体系是我们在这些通用的运维方法论基础之上,做了相应的融合、抽象、提炼,并结合国内运维现状及未来趋势所提出的概念。
IT运维(IT Operations)、ITSM(IT Service Management)和ITIL(IT Infrastructure Library)是与IT管理和服务相关的三个概念,它们在范围和目标上存在一些差异。下面是它们的主要区别:
####本篇转自老王在51CTO的一次线上交流,感谢峻峻Aily的整理,即时打字,不免错漏,请见谅。欢迎51CTO微信号:51CTO博客
其实在今天的运维领域,ITIL和DevOps之间的冲突还是蛮明显的,有些是表现在产品上,有些是表现在思维/理念上。ITIL在产品上以流程为核心目标的设计,很难满足自动化的要求,DevOps极力推崇工具/平台/自服务文化;理念也是如此,ITIL以流程为先介入到一个企业的IT过程。本质上来说,这两者不是同一个东西,但聚焦到运维领域,这个问题值得对比探讨一下。
ITSM起源于ITIL(IT Infrastructure Library,IT基础架构标准库),ITIL是CCTA(英国国家电脑局)于1980年开发的一套IT服务管理标准库。它把英国在IT管理方面的方法归纳起来,变成规范,为企业的IT部门提供一套从计划、研发、实施到运维的标准方法。
前言: 本文将介绍《DevOps Handbook》全书中的一部分:对 DevOps 常见误区进行解读。有些朋友对DevOps不熟悉或有一些不准确的理解,比如是不是只有互联网公司可以仅仅,是不是与ITIL不兼容,是不是做DevOps就不能同时保证质量和效率等,我们会对这些常见误区进行分析。 驱散谬见-常见DevOps误区解读 在DevOps推广过程中有非常多的声音,有人说 DevOps 只适合特定的公司、特定的企业、特定的文化,他们的公司很难去推广 DevOps 活动。所以在《DevOps Handbook
在之前的文章中,谈到过【运维的本质--可视化】,在可视化的篇幅中,着重介绍自动化的可视化和数据的可视化;在后续的篇章中又介绍了【互联网运维的价值体系】,里面分解了几个维度:质量、成本、效率、安全等。以上都是为了清楚的梳理运维的内容边界,基于这个边界,我们再考虑如何进行平台支撑。可以说前两篇文章都是为今天这篇文章作为铺垫,用理念先行,然后在考虑平台落地,最后在细化其中每个内容。我更习惯用如下的方式来整体表达运维的工作方法和思路;
在运维适应性系统中,随着运维能力需求不断提升,运维组织面临的机器、人、协同关系等不确性特征越来越明显。为了更好的传递公司数字化转型价值创造,确保公司价值产出过程的有序运作,需要建立以价值驱动的运维流程管理,以持续提升运维组织整体运作效率和价值实现,落实运维的能力建设。良好的流程可以帮助运维建立复杂环境的适应性能力,即围绕“需求、改变、风险、适应”四个要素闭环螺旋上升(闭环模型参见《运维挑战:如何构建复杂环境下的适应性系统》)。
在今天,配置管理数据库(CMDB,后面均用这个简称,并且暂时不去区分CMDB和CMS)这个名词对于IT从业人员来说一点都不陌生,甚至有点烂熟了。无论是ITIL在企业落地、自动化运维、标准化运维、DevOps、端到端统一监控,甚至最时髦的运维大数据、智能运维(AIops)等都很难绕开CMDB这个概念。说CMDB是企业IT运维标准化、自动化、数据化和智能化的基石,相信现在应该没有多少人反对了。
CMDB作为企业运维的IT主数据,在建设初期企业常常“报以厚望”,希望通过CMDB的建设,为IT运维体系的建设打好基础,为后续更多的运维系统提供数据支撑,提高业务连续性。但往往建设完毕后出现弃用、推广难等问题,根本用不起来,而原因一般都较为复杂。本文将从CMDB在两种应用场景中的作用,简单讲述为什么CMDB建设后很难推广使用。
进入数字化时代,IT架构面临的复杂性越来越高,业务连续性管理这项IT最基本的工作,也成为了很多行业或企业IT运维的最核心任务;业务连续性管理是一个持续不断提升的过程,围绕“快速发现事件→快速响应事件→快速定位与处理事件→减少事件发生”的事件生命周期闭环,结合一体化运维平台,是提高业务连续性保障水平的一种好思路。
随着企业规模的扩张,企业IT系统正变得越来越复杂,其管理难度也在逐步增加。自信息技术融入到企业业务发展以来,经过20多年的发展,从早期的OA、CRM到后来的ERP,再到今天的MES、DCS等系统,企业信息化进程一再深入,业务自动化程度大幅提高,极大的提升了企业运转效率。而作为一系列业务系统的支撑,企业对IT系统的管理却不够重视,长久以来,企业管理者“重建设,轻运维”,“重技术,轻管理”的思维导致了IT系统与业务系统的长期脱节,当业务系统变得越来越复杂,累赘的IT系统已经无法灵活适应企业业务的调整需求。同时,由于企业的IT系统建设没有一个清晰的规划,也导致企业IT运维成本居高不下,“救火式”的人工IT运维普遍存在。这种低效的IT运维模式不断严重影响企业业务运转效率,也降低了企业竞争力,已无法适应新时代企业的发展需求。企业需要更高效的IT运维管理系统来支撑企业的发展。
原计划是写名字服务相关的一篇文章,但因为周末出去培训,实在没法完成。公司组织大家出去讨论关于协同效率问题,之前在腾讯也讨论过部门墙的问题。随着公司的日益增大,这类问题会一直存在,且一直在解决而不能彻底
在之前的文章中,谈到过“运维的本质——可视化”,在可视化的篇幅中,着重介绍自动化的可视化和数据的可视化;在后续的篇章中又介绍了“互联网运维的价值体系”,里面分解了几个维度:质量、成本、效率、安全等。以上都是为了清楚地梳理运维的内容边界,基于这个边界,我们再考虑如何进行平台支撑。可以说前两篇文章都是为今天这篇文章作为铺垫,用理念先行,然后再考虑平台落地,最后再细化其中每个内容。我更习惯用如下的方式来整体表达运维的工作方法和思路:
要做一个IT运维管理的项目,客户提到了ITIL(IT Infrastructure Library),所以谈需求之前我研究了一下ITIL,发现东西比较多,但是里面的服务运维部分是项目一期所需要的,那我就把我这部分的学习笔记贴一下。
几年前,在gartner的魔力象限中看到过servicenow这个名字,由于身处金融行业,对saas偏保守的态度,并没有太多关注。今天,servicenow是全球itsm领域领先的独角兽企业,提供saas的解决方案,是全球三大saas公司之一, 作为对itom的发展持续保持关注的从业者,很值得我对servicenow进行一些分析。所以,借着前期与servicenow公司一次交流机会,以下汇集一些非严谨的研究内容。
在金融企业中,IT组织架构通常包括以下职能:IT规划管理,即根据公司战略及业务发展,设计IT体系架构和部署线路;IT研发管理,即根据现有IT系统架构和系统,受理业务功能优化需求,支持业务开展;IT运维管理,即提供基础设施环境支持,确保业务连续性、可用性、安全性,提供IT运营服务支持;以及,其他IT项目管理、人员管理、外包管理等。在这样的组织架构中,IT部门主要承担成本中心角色,主要以技术提供者身份出现,强调被动支持业务需求与运行保障。随着业务与科技的快速发展,IT系统环境发生了巨大变化:架构层逐渐从本地化转向云化、虚拟化,应用层的应用数量激增,迭代速度加快,业务复杂度与系统架构越来越复杂,系统间关联度高,数据量呈指数级增长等,而现有被动支持业务需求的成本中心的工作模式将受挑战。因此,IT部门需要由被动向主动转型,首先是向强调IT主动服务能力的服务中心角色转型,目标是打造敏捷型的团队,提升IT交付效能,更好的支撑业务发展的需要。在实现服务中心后,下一步是关注并致力主动利用数字化技术创造新的业务机会,从IT资源中寻求更多的业务突破,引领业务创新,即由服务中心向业务创新中心转型。在实现业务创新中心的同时,近年来不少商业银行在向利润中心转型,为企业外部市场提供IT服务,从而为企业创造更多收入。
工单系统,又称为工单管理系统,是用来记录、处理、跟踪一项工作完成情况的。工单系统分为两大类:一是企业内部部门工作任务传达的系统,比如公司内一般都会有办公电脑报障类工单,是由办公人员提单、信息部员工接受并解决工单的流程;二是专门用于售服或安装维修类的系统,这种是把工单派给客服进行解答或让外勤人员上门去维护的软件。
DevOps是开发和运维的结合,有助于集成和自动化测试过程以及部署存储库,还提供了透明度以及灵活性。DevOps的目标如下:
小编说:DevOps 领域在近年来变得流行而普遍。由开发(developers)和运维(operations)组成的“共同协作”,归根结底,就是为了提高产品质量。
我一直把运维团队的定位是在技术服务团队,个人也要朝着技术服务的方向去发展。单纯的服务定位对整个团队的发展不是非常有利,会逐渐沦为救火队员和保姆的角色,有点高级人员干着低级的活的感觉。
之前建设4大的ITSM系统(IBM、BMC、HP、CA),由于架构传统,功能模块固化,加之受到国产化政策的影响,研发和技术支持中心已撤出中国,企业基本不考虑再续费或升级。而现有4大的ITSM系统通常是5、6年前的版本了,如果不升级到最新版本,又会面临诸多的体验问题,如下:
本文引用艾瑞咨询《2020年中国IT基础架构运维市场研究报告》中的内容。目的是引导读者关注IT运维管理领域的市场环境,行业客户的需求情况,以及竞争格局。特别是金融行业数字化对IT运维管理的需求。
关于CMDB使用过程中的一次总结,通过CMDB的认识、进化、流程规范支撑、运维场景驱动等方面的介绍,让我们快速了解
内容来源:2017年5月6日,王津银在“DevOps&SRE 超越传统运维之道”进行《DevOps与传统的融合落地实践》演讲分享。IT大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。 阅读字
DevOps理念广受青睐。在现实中,DevOps同样遭受地盘之争,而传统IT也没有适合的工具提供支持。它同样给IT带来不少新挑战,包括来自同行的孤立与非结构化的部署途径。 “因为团队正在尝试新的流程与工具,没有什么完美的方案可循,”CommerceHub 的质量总监Vijaya Kokkili说,该公司为电子商务零售商提供技术支持。“我们无意间发现了一些问题,而且其中一些仍然没有答案。” 在公司采用DevOps的两年里,Kokkili看到了转型与新现实的两个挑战。 “我们本来希望将许多标准做到位,但事实却很
没有比“可视化”更好的一个词能概括运维的本质,而“可视化”又应该分成两部分:可视化的服务交付和可视化的服务度量!
2022年11月,嘉为蓝鲸IT服务管理中心正式发布V3.0版本,以提升管理效率及用户体验,助力实现企业IT服务管理体系的升级,满足当前及未来运维管理所需。
谈起运维工作,估计很多人会下意识的认为就是修电脑的、网管(上不去网,第一个被召唤的那种)。其实不能说这是错误的理解,IT运维人员的工作小到修电脑、理网线,大到部署整个数据中心。
ITIL/ISO20000国际标准、ITSM/ITIL软件(即IT运维管理软件、IT服务管理软件)、及其所带来的IT管理水平的提升,越来越受到国内各类单位和机构的IT部门的重视和关注,那么,在当今时代的中国国内面临哪些发展趋势?下面是笔者的一些观察、分析、和总结: 第一,ITSM/ITIL软件的移动化。移动将是主导性力量,从终端用户到运维人员的每一个电话、每一条服务请求,从报故障、报变更、提交发布、提交知识、指派工单、到相关审核、更新CMDB等等操作都依赖实时信息。对于那些拥有众多终端用户的企业来说,关键ITSM/ITIL软件系统的移动化将带来数据的实时化,快速提升服务的执行力、效率、业绩。在类似平板电脑的移动设备上提供ITSM/ITIL软件移动应用将是未来ITSM/ITIL软件市场的一大亮点。毕竟,企业中的用户们、管理者们使用iPad、iPhone、智能手机的比例越来越高,ITSM/ITIL软件移动化的效果对他们来说也非常直观。 第二,ITSM/ITIL软件的国产化。这是国家对信息安全管理的需要,已经是不争的事实了,尤其是对信息安全要求比较严格、敏感的企事业单位、国家机关等等;甚至包括相关的配套数据库、办公软件、操作系统、硬件等等也都有同样的国产化要求。那么,管理软件对这些国产配套系统的跨平台能力就很重要。 第三,在中端市场(或者,SAAS模式云端租用市场),产品化、模板化将是ITSM/ITIL软件的主流趋势,而非“项目化”。很多中型企业更加关注ITSM/ITIL软件的实施和投入运营的速度,尽量减少定制化开发。对于面向垂直行业的云ITIL软件系统来说,模板化将成为主流。模板化有利有弊,可以大大缩短实施时间,但同时灵活性上有些折扣。适合模板化的ITSM/ITIL软件应用几乎包括了所有常用的ITIL软件模块。对于很多垂直行业来说,模板化ITSM/ITIL软件非常有利于企业的政策合规、信息安全合规。 第四,高度专业化的ITSM/ITIL软件平台(例如国津软件的ITSM云端平台、就包括公有云的平台、私有云的平台、以及二者整合的解决方案)将加速系统实施、提高回报,同时将改变ITSM/ITIL软件业态。这将颠覆传统的企业管理软件产品的开发、销售和服务模式。 第五,社会化网络技术将对新一代的ITSM/ITIL软件发展产生重大影响。对于CIO、IT经理们来说,社会化ITSM/ITIL软件技术意味着可以通过升级图形界面来满足不同部门和客户的需求,无需彻底抛弃旧系统。
《DevOps实践指南》前言 介绍 在访谈了‘DevOps之父’Patrick Debois之后,我深刻地理解了‘DevOps is the Human Factor’这句话的真谛 DevOps更多的是实践而不是角色 通过“三步工作法”铺平流程,选择合适的切入点,根据康威定律调整组织、持续交付、自动化、运维改善等 “基础设施即代码”(infrastructure as code)理念 运维人员的工作模式可能会变得像开发人员一样,他们必须在源代码控制系统里维护系统的配置,并在工作中使用持续集成/持续交付(CI
哈啰出行-运维架构专家/高级专家 100W + 期权 工作职责 1、 自动化运维工具和平台的设计和开发; 2、 应用性能监控,资源监控平台的设计和开发; 3、理解业务需求,识别系统风险,设计稳定性方案。负责高可用体系建设,如监控体系完善、故障定位、自动恢复等 ; 4、参与基础架构优化,优化工具平台:发布平台、运维自动化平台、配置管理平台等 5. 有行业眼光,持续提升运维效率和系统稳定性,引入优秀理念和工具。推动DevOPS文化理念,不断提升运维自动化水平; 任职资格 1、5年以上系统运维或者运维平
为加快数字经济建设,推动金融高质量发展,金融行业正大力推进数字化转型。IT运维管理作为企业运营中的环节,在数字化浪潮下,应主动出击,进行数字化能力升级,发挥自己独特的价值。
随着企业信息化的不断发展,运维人员需要面对越来越复杂的业务和越来越多样化的用户需求,不断扩展的应用需要越来越合理的模式来保障运维服务能灵活便捷、安全稳定地持续。
ITIL v1 版本的诞生,传说是因为马岛战争中的一次导弹发射系统的故障,引起了英国 政府的高度重视,从而采用各行业在信息化管理方面的最佳实践(Best Practice),形成了 最初的出版物。不过,让 IT 领域认为最经典的 ITIL 版本是诞生于 1989 年的 ITIL v2,至今 大家都很熟悉里面所提到的十大管理流程(事件、问题、变更、发布、配置、财务、服务级 别、可用性、容量、连续性)和一个职能(服务台)。实际上,ITIL v2 版本的内容并不只是 这些,但这些是最为 IT 人员,尤其是 IT 运维人员所推崇的,如今在全球,已经被广泛实践 了。
前天在51CTO群里面,大家问我运维知识地图的问题,我想到了一篇文章。这篇文章是在去年公司运维通道面试,自己作为评委参与了整个过程,然后写了一个总结发表在运维知识库,虽然是建议未来的运维职级晋升者如何应对(类似攻略),但其实看到的是对运维人的要求,供大家参考~
前言 大家上午好,我会很快介绍一下自己,我的名字叫Kris,我和Patrick一起在很多年之前开始做DevOpsDays。我做这个行业已经有20年了,我最开始是做开发,然后又开始成为了运维人员,所以这
ITSM(IT 服务管理)建设通常被认为仅仅把几个核心 ITIL 流程设计好,并通过工单系统来承载流程的审批和流转即可。这种方式可能是大多数企业的最初做法,用于满足运维管理的合规性需求,以确保工作过程有审批和记录可查。在这种要求下,一个 ITSM 系统确实只要具备了提单、审批、处理等基本的流程功能就已足够,相当于一个电子工单系统。
能力管理(Capacity Management)应该是ITIL里面一个非常重要的概念,有些人叫容量管理,但我还是觉得能力管理更好一些,能力直接的理解就是我们能做什么?还有多少能力冗余?让我们来看看ITIL的概念解释,指在成本和业务需求的双重约束下,通过配置合理的服务能力使组织的IT资源发挥最大效能的服务管理流程,ITIL给到的流程图如下:
在#DevOps的前世今生# 1. DevOps编年史一文中,通过追溯 DevOps 活动产生的历史起源,我们发现了 DevOps 是敏捷思想从软件开发端(Dev)到系统维护端(Ops)的延伸。无论是 DevOpsDays 的创始人 Patrick Debois,还是同时期的 The Agile Admin。都想通过敏捷来改进传统的系统维护工作以及软件开发部门和系统维护部门的合作关系。但是,DevOps 的矛盾从何而来?这还要从 Dev 和 Ops 的起源开始讲起。
领取专属 10元无门槛券
手把手带您无忧上云