互联网时代的网络自动化运维

互联网时代的网络自动化运维,第1张

互联网时代的网络自动化运维

互联网上有两大主要元素"内容和眼球","内容"是互联网公司(或称ICP)提供的网络服务,如网页、游戏、即时通信等,"眼球"则是借指海量的互联网用户。互联网公司的内容往往分布在多个或大或小的IDC中,越来越多的"眼球"在盯着ICP所提供的内容,互联网公司进行内容存储的基础设施也呈现出了爆发式的增长。为了保障对内容的访问体验,互联网公司需要在不同的运营商、不同的省份/城市批量部署业务服务器用以对外提供服务,并为业务模块间的通信建立IDC内部网络、城域网和广域网,同时通过自建CDN或CDN专业服务公司对服务盲点进行覆盖。因此随着业务的增长,运维部门也显得愈发重要。他们经过这些年的积累,逐步形成了高效的运维体系。本文将结合国内互联网公司的经验,重点针对IT基础设施的新一代自动化运维体系展开讨论。

一、运维的三个阶段

● 第一个阶段:人人皆运维

在早期,一个公司的IT基础设施尚未达到一定的规模(通常在几台到几十台机器的规模),不一定有专门的运维人员或部门,运维的工作分担在各类岗位中。研发人员拥有服务器权限,自己维护和管理线上代码及业务。

● 第二个阶段:纵向自动化

随着业务量的增长,IT基础设施发展到了另外一个量级(通常在上百台至几千台机器的规模),开始有专门的运维人员,从事日常的安装维护工作,扮演"救火队员",收告警,有运维规范,但运维主要还是为研发提供后置服务。

这个阶段已经开始逐步向流程化处理进行过渡,运维部门开始输出常见问题处理的清单,有了自己业务范围适用的自动化脚本,开始利用开源软件的拼装完成大部分的工作。

具体表现为:各产品线有自己编写的脚本,利用如SVN+puppet或chef来完成服务器的上线和配置管理等工作。

● 第三阶段:一切皆自动

在互联网化的大潮中,越来越多的黑马团队应运而生,都曾有过短时间内用户访问量翻N倍的经历。在流量爆发的过程中,ICP的互联网基础服务设施是否能够很好的跟进,直接决定了业务内容能否满足海量用户的并发访问。

与此同时,运维系统需要足够地完善、高效、流程化。谷歌、腾讯、百度和阿里等规模的公司内一般都有统一的运维团队,有一套或多套自动化运维系统可供参照,运维部门与开发部门会是相互平行的视角。并且也开始更加关注IT基础设施在架构层面的优化以及超大规模集群下的自动化管理和切换(如图1所示)。

图1大型互联网公司IT基础设施情况概览

二、BAT(百度、阿里、腾讯)运维系统的分析

国内的互联网公司百度、阿里、腾讯(以下简称:BAT)所提供的主要业务内容不同,IT架构不同,运维系统在发展过程中有不同的关注点。

1腾讯运维:基于ITIL的运维服务管理

预计到2015年腾讯在全国将拥有60万台服务器。随着2012年自动化部署实践的成功,目前正在进行自动化验收的工作。在网络设备方面,后续将实现从需求端开始的全自动化工作:设备清单自动生成->采购清单自动下发->端口连接关系、拓扑关系自动生成->配置自动下发->自动验收。整个运维流程也已由初期的传统IT管理演进到基于ITIL的服务管理流程(如图2所示)。

图2腾讯基于ITIL的运维服务管理

2阿里运维系统:基于CMDB的基础设施管理+逻辑分层建模

CMDB(Configuration Management Database) 配置管理数据库(以下简称:CMDB),将IT基础架构的所有组件存储为配置项,维护每个配置项的详细数据,维护各配置项之间的关系数据以及事件、变更历史等管理数据。通过将这些数据整合到中央存储库,CMDB可以为企业了解和管理数据类型之间的因果关系提供保障。同时,CMDB与所有服务支持和服务交付流程都紧密相联,支持这些流程的运转、发挥配置信息的价值,同时依赖于相关流程保证数据的准确性。可实现IT服务支持、IT运维以及IT资产管理内部及三者之间的流程整合与自动化。在实际的项目中,CMDB常常被认为是构建其它ITIL流程的基础而优先考虑,ITIL项目的成败与是否成功建立CMDB有非常大的关系。

3百度自动化运维:部署+监控+业务系统+关联关系

百度主要面临的运维挑战包括:突发的流量变化、复杂环境的关联影响、快速迭代的开发模式以及运维效率、运维质量、成本之间的平衡等等。百度的运维团队认为,当服务器规模达到上万台时,运维视角需要转为以服务为粒度。万台并不等于"百台100";机器的运行状态,也不再代表业务的工作状态;运维部门为研发提供前置服务,服务与服务之间关系也随着集群的扩大逐渐复杂起来。

图3百度自动化运维技术框架

百度的自动化运维技术框架,划分为部署、监控、业务系统、关联关系四大部分,整个框架更多突出了业务与IT基础设施的融合,注重"关联关系"的联动。所谓关联关系,主要是指任务与任务之间的时序依赖关系、任务与任务之间的数据依赖关系、任务与资源之间的引用依赖关系,分别对应到任务调度、数据传输、资源定位的服务流程中,形成了多条服务链。

关联关系的运维与业务较强相关,需要有一套系统能够理清楚关系的全貌,从而在复杂的服务链上,定位运行所在的环节,并在发生故障时预估影响范围,及时定位并通知相应的部门。在这样的一套系统中,自动化监控系统非常重要。百度的技术监控框架,主要通过数据采集、服务探测、第三方进行信息收集,进行监控评估后交给数据处理和报警联动模块处理,通过API接口进行功能扩充(如图4所示)。

图4百度自动化技术监控框架

其实无论是BAT等互联网企业还是其他行业的企业,在IT建设中都会遵循IT基础架构库(ITIL)或ISO20000服务管理的最佳实践,采用自动化IT管理解决方案以实现重要的业务目标,如减少服务中断、降低运营成本、提高IT效率等等。随着ISO20000、ITIL v30的发布和推广,两者已经成为事实上的某种标准。在当今企业IT管理领域,对两个标准有着很迫切的需求。特别是ISO20000的认证要求,已经成为企业越来越普遍的需求 。ITIL v30包含了对IT运维从战略、设计到转换、运营、改进的服务全生命周期的管理,相关方案往往覆盖了多个领域和多个产品,规划实施和工具的选择会比较纠结。如果选择开源的工具,从CMDB开始就会遇到很多的开发工作,对于很多注重成本收益比的企业,可以参考,但由于无法保证性能与效果并不一定适用。因此,成熟的商业方案会是更好的选择。

最新的iMC V7版本,围绕资源、用户、业务三个维度进行创新,发布了SOM服务运维管理(基于ISO20000、ITIL标准)等组件,增加了对服务器的管理,能很好的满足更多互联网化的场景需求。

通常认为,一个高效、好用的配置管理数据库一般需要满足6条重要标准,即联合、灵活的信息模型定义、标准合规、支持内置策略、自动发现和严格的访问控制。企业IT基础架构的元素类型、管理数据的类型往往有较多种,如网络设备、服务器、虚拟机等,因此对于多种信息的存储需要有合适的联合的方法。虽然 iMC智能管理平台在网络设备、服务器设备等方面已经能够较好的的满足,但是随着服务器虚拟化技术的发展,虚拟机正越来越多的成为IT基础架构的一大元素。因此,针对这一需求华三通信基于CAS CVM虚拟化管理系统,对服务器CPU、内存、磁盘I/O、网络I/O等更细节的重要资源以及虚拟机资源进行全面的管理。与BAT不同,华三通信的网管软件面向全行业,目前虽然没有对域名管理等特殊资源的'管理,但是能够通过API接口等方式与特有系统进行联动,进而满足定制化运维的需求,尤其是在互联网化的场景中,针对不同的业务需求,可以实现很多定制化的对接需求,例如,iMC+WSM组件与国内某大互联网公司自有Portal系统进行了对接,打通了iMC工具与用户自有运维平台,很好的实现了架构融和。另外,与阿里的逻辑分层建模相似,H3C "iMC+CAS"软件体系在上层也做了很多的逻辑抽象、分层,形成了诸多的模块,也即是大家看到的各种组件。

三、网络自动化运维体系

"哪怕是一个只有基础技术能力的陌生人,也能做专业的IT运维;哪怕是一个只有初中学历的运维人员,也能够带队完成中小型机房节点的建设,并负责数百至上千台服务器的维护管理工作"--这是一些公司对自己IT运行维护水平的一个整体评价。看似有些夸大的嫌疑,但实际上依托于强大的IT运维系统,国内已经有不少互联网公司能够达到或者接近这一标准。

这些企业都经历了运维发展过程中的各个阶段,运维部门曾经也是被动的、孤立的、分散的"救火队"式的团队,在后来的发展过程中,IT系统架构逐渐走向标准化、模型化,运维部门建立了完整的设备、系统资源管理数据库和知识库,包括所有硬件的配置情况、所有软件的参数配置,购买日期、维修记录,运维风险看板等等,通过网管软件,进行系统远程自动化监控。运维过程中系统会收集所有的问题、事件、变更、服务级别等信息并录入管理系统,不断完善进而形成一套趋向自动化的运作支撑机制。按照云计算的体系架构,在这样一套系统中,主要的IT资源包括计算、存储、网络资源,近些年随着网络设备厂商的推动,网络设备管理方面的自动化技术也得到十足的发展。

总结来看,一个企业在进行互联网化的建设初期,就需要考虑到随着用户访问量的增加,资源如何进行扩展。具体可以细化为规划、建设、管理、监控、运维五个方面。

1规划模型化

为了确保后续业务能够平滑扩容,网管系统能够顺利跟进,互联网企业一般在早期整体系统架构设计时便充分考虑到标准化、模型化,新增业务资源就好比点快餐,随需随取。

标准化:一是采用标准协议和技术搭建,扩展性好,使用的产品较统一,便于管理;二是采用数据中心级设备,保证可靠性、灵活性,充分考虑业务系统对低时延的要求。

模型化:基于业务需求设计网络架构模型,验证后形成基线,可批量复制,统一管理,也适宜通过自动化提高部署效率、网管效率。

图5常见互联网IDC架构

2建设自动化

互联网IT基础设施具备批量复制能力之后,可以通过自动化技术,提高上线效率。在新节点建设过程中,3~5人的小型团队即可完成机房上线工作。例如某互联网公司某次针对海外紧急业务需求,一共派遣了2名工程师到现场进行设备安装部署和基本配置,而后通过互联网链路,设备从总部管理系统中自动获取配置和设备版本,下载业务系统,完成设备安装到机房上线不超过1周时间。

要达到自动化运维的目标,建设过程中需要重点考虑批量复制和自动化上线两个方面(如图6所示)。

批量复制:根据业务需要,梳理技术关注点,设计网络模型,进行充分测试和试点,输出软、硬件配置模板,进而可进行批量部署。

自动化上线:充分利用TR069、Autoconfig等技术,采用零配置功能批量自动化上线设备,效率能够得到成倍提升。

图6批量配置与自动化上线

○ Autoconfig与TR069的主要有三个区别:

○ Autoconfig适用于零配置部署,后续一般需要专门的网管系统;TR069是一套完整的管理方案,不仅在初始零配置时有用,后续还可以一直对设备进行监控和配置管理、软件升级等。

○ Autoconfig使用DHCP与TFTP--简单,TR069零配置使用DHCP与>

ITIL(IT Infrastructure Library,IT基础架构标准库),是英国国家电脑局(CCTA)于1980年开发的一套IT业界的服务管理标准库。它把英国各界在IT管理方面最好的方法归纳起来,变成规范,旨在为企业的IT部门提供一套从计划、研发、实施到运维的标准方法。这套标准已经被欧洲、美洲和澳洲的很多企业采用,目前全球已经有1万多家知名的公司在参考其中的方法管理自己的IT系统。

ITIL的目标是在找出对IT顾客而言真正需要的程序,而这些程序正是提供高品质、最合适的服务所必要的,而且是在可接受的成本下。 IT基础建设中有哪些需要管理?有硬件、软件、程序、文档、人员。ITIL可以部分或全部采用,很适合用来做为管理平台的基础。

服务器运维工程师需要收集、整理所有技术问题和客户意见,反馈给相关部门或人员。下面是我为大家带来的服务器运维工程师工作的具体内容十篇,希望大家能够喜欢!

服务器运维工程师工作的具体内容1

职责:

1、负责公司网站服务器安装及配置;

2、负责公司网站及服务器的稳定运行,监控网络状态、及时排除各种异常,优化配置软硬件资源;

3、负责服务器和网站的安全工作,定期进行安全漏洞扫描分析和入侵检测并提出解决方案;

4、负责数据库备份、数据迁移、数据监控,编制汇总故障、问题,定期提交汇总 报告 ;

5、负责公司网站服务器集群部署,优化负载及容灾;

6、负责网络监控和应急反应,以确保网络系统有7 24小时的持续运作能力。

任职资格:

1、大专以上学历,熟悉信息安全体系和安全标准,对信息安全体系和安全风险评估有较全面的意识;

2、精通服务器及网络安全产品配置原理,如防火墙、身份认证、漏洞评估、网络防病毒;

3、熟悉TCP/IP协议,熟练掌握网络相关设备的配置技术,如路由器、交换机、防火墙、负载均衡器等,有服务器集群部署相关 经验 ;

4、熟悉常见的网络攻击和防守技巧(包括服务漏洞扫描、程序漏洞分析检测、入侵和攻击分析追踪、病毒、木马防范。熟悉SQL注入原理和手工检测);

5、 熟悉Linux下各种环境搭建配置及维护;

6、 熟悉MYSQL等数据库配置、维护、优化;

7、 精通shell、python、perl、PHP脚本语言之一;

8、具有至少2年以上的共有云运维经验。

服务器运维工程师工作的具体内容2

职责:

1负责IDC机房内服务器的日常维护工作

2服务器系统的安装/调试/环境配置/安全配置

3排除简单网络故障,交换机简单调试及流控

4和其他部门协调,支持其他部门工作

5按公司规定接受和处理客户问题,为客户提供优质服务及日常上、下架工作。

任职要求:

1、计算机或相关专业专科以上学历。

2、熟悉Windows/Linux常用网络服务的系统安装配置与使用

3、熟悉二层交换机,有网络维护经验者优先考虑

4、熟悉Docker者优先考虑

5、有良好的沟通能力、团队协作精神

服务器运维工程师工作的具体内容3

职责:

1、执行和监督执行服务器系统管理制度;

2、日常驻场维护工作:PC服务器设备维护,发现异常后的应急处理以及故障的排查和解决;针对PC服务器系统提出相应的软硬件优化方案;

3、客户服务、系统集成及相关工作;

4、运维服务文档, 总结 报告撰写等相关工作。

任职条件:

1、大专或以上学历;

2、两年以上PC服务器系统维护经验;

3、精通PC服务器硬件架构、Windows server、Linux等 *** 作系统 配置;

4、熟悉VMWARE虚拟机系统和配置。

服务器运维工程师工作的具体内容4

1、数据中心服务器计算与存储规划、建设和运维,

2、系统建设和优化项目管理,制订和实施网络优化方案,提升平台指标,提高业务系统的网络性能和速度,提升使用效率。

3、负责故障排查和应急处理,确保任何突发情况都能高效响应,保证系统7x24小时正常稳定运行;

4、制订服务器和存储相关系统建设标准,推进实现平台运维标准化管理。

5、网络安全推进和协同。

服服务器运维工程师工作的具体内容5

1、对服务器进行日常维护,确保各项服务连续正常运行,无重大事故;

2、负责服务器存储网络等基础平台的技术维护和问题处理 ;

3、负责执行大客户服务项目的定制化服务配置和硬件安装等处理工作;

4、了解 *** 作系统安装与配置;

5、具备一定的网络相关故障解决能力;

6、熟悉主流厂商PC服务器硬件安装与配置;

7、Windows、Linux、VMware等日常管理、维护;

8、负责服务器异常或故障的受理、跟踪、解决以及统计分析;

服务器运维工程师工作的具体内容6

职责:

1、负责IBM、HP、DELL等业界主流品牌的服务器安装配置及日常维护工作;

2、负责VMWare虚拟化平台项目实施及维护工作;

3、负责EMC、DELL等企业级存储及其SAN网络的安装配置及日常维护工作;

4、负责服务器集群拓扑及SAN存储网络部署;

5、解决实施工作中的技术难题,挖掘客户需求,提出针对性的解决方案;

6、编写各类维护文档,譬如: 实施方案 、实施报告、巡检报告、故障处理报告等等。

岗位要求:

1、计算机相关大专以上学历,3年以上IT运维或机房管理工作经验;

2、熟悉主流X86服务器(IBM/HP/华为)和存储的运维和管理;

3、熟悉思科、华为等主流网络设备的配置和问题排错;

4、熟悉vmware虚拟化架构技术,具有虚拟化的搭建和运维经验,对vmware的存储、灾备、网络、安全、升级、虚拟机管理、监控和性能等有深刻的理解;

5、有一定的信息安全实施经验,对 *** ,防火墙,上网行为管理以及内网安全有深入理解和实 *** 经验;

6、熟悉服务器运维及服务器架设,包括AD域,IIS,DNS、双机集群等各类windows服务器的配置管理;

7、熟悉openstack或者cloudstack任意一种平台的部署实施,有成功搭建或者部署经验优先。

服务器运维工程师工作的具体内容7

职责:

1 负责或参与智能连接产品(智能耳机,音箱等)后端系统的设计、代码实现;

2 参与制定前后端业务流程、接口协议、文档输出等;

3 负责或参与前端程序(APP, Device)的对接、调试;

4 持续迭代开发,改善系统性能,用户体验。

岗位要求

1 五年以上服务器端开发经验,一年以上Go语言开发经验;

2 熟悉linux,对服务器性能优化有一定了解,有高并发项目经验优先;

3 熟练掌握nginx、mongodb、Redis等开源组件;

4 了解服务器安全配置相关的知识;

5 熟悉多线程和网络编程,有分布式系统项目经验者优先;

6 有可穿戴产品后台开发经验者优先。

服务器运维工程师工作的具体内容8

职责:

1、负责公司系统集成项目中HP、DELL等服务器及IBM、NetApp、HDS等存储产品的初始化安装、技术支持、维护等工作。

2、根据客户的应用环境及需求,独立完成整体项目规划和实施;

3、创建相关的技术实施方案,并在实施过程中提供技术支持;

4、服务器发生系统故障时的分析与解决,在售后服务体系中提供现场支持工作。

岗位要求:

1、计算机、通信工程等相关专业 毕业 ,大专及以上学历

2、两年以上服务器工程师经验,熟练掌握Linux/Windows系统,了解Oracle、SQL sever数据库

3、熟悉HP、Dell等主流服务器厂商产品,具备系统、数据库和存储的整体概念,对存储应用系统有一定的了解

4、具有以下技能资格优先考虑:

服务器运维工程师工作的具体内容9

职责:

1负责项目中Wintel服务器的搭建部署配置,排错、故障处理, 备份恢、等工作。

2负责项目中Wintel服务器HA测试,BUR 测试,DR测试等相关工作。

3熟悉Windows server的日常运维,如日常巡检、备份、故障排查、漏洞修复、优化等工作。

4熟悉微软AD、Exchange、SCCM等相关应用运维工作。

5熟悉VMWARE虚拟化平台的日常运维管理

6熟悉EMC存储设备。

8DCS项目管理经验

任职要求:

16年以上金融行业Wintel server及AD、Exchange、SCCM运维管理经验。

2精通Windows server 2008/2012/2016

3熟练使用powershell编写脚本。

4熟练使用VM环境,具备VMWARE相关知识。

5良好的团队协作沟通能力,较强的学习能力。

6具备较好的英语书写能力及文档方案写作能力。

7熟悉ITIL服务流程。

8具备MSCE,VMWARE及ITIL ,PMP相关认证者优先考虑。

9有良好的抗压能力。

10金融企业数据中心迁移项目经验。

服务器运维工程师工作的具体内容10

职责:

1负责健康平台等系统后端服务开发;

2参与项目的需求分析,负责项目的设计和开发;

3 良好的编程习惯,根据项目任务计划独立按时完成高质量的编码和测试工作;

4 配合测试人员进行bug修复、完善产品功能体验。

任职要求:

1精通Golang或PHP、Nodejs等语言,3年以上Web开发经验,具有高并发开发工作经验;

2精通 Mysql及Nosql 数据库(Memcached、Redis 等);

3熟悉一种 web开发框架(Golang/PHP);

4对分布式、高可用、高性能,海量数据处理设计及开发有一定实践经验;

5较强的分析问题解决问题能力,工作踏实上进,有良好的团队合作意识 ,有大型互联网工作经验优先。

服务器运维工程师工作的具体内容相关 文章 :

★ 运维服务工程师的具体职责

★ 网络运维工程师岗位职责具体内容

★ 系统运维工程师工作职责都有哪些

★ 系统运维工程师工作职责具体内容

★ 网络运维工程师岗位的基本职责概述

★ 系统运维工程师工作职责与任职要求

★ 网站运维工程师的具体职责范围

★ 网站运维工程师的主要职责概述

★ 系统运维工程师的具体内容

★ 大数据运维工程师的具体职责描述

var _hmt = _hmt || []; (function() { var hm = documentcreateElement("script"); hmsrc = ">

IT运维管理发展成熟,目前较为普遍应用的为ITIL流程管理。有人将ITIL比喻成IT管理中“黑夜航行的灯塔”,这光芒万丈的词汇吸引了无数个企业或是准备、或是已经开始在IT运维服务管理中实现标准化运维。而我们知道,在ITIL强大的流程管理面前

当企业开始转型时,作为CIO不仅要为IT打算,还要为公司业务考虑。CIO利用精益IT的概念,将业务划分为“核心”和“边缘化”两种,促使IT和业务部门全力以赴支持“核心”、放弃“边缘化”业务。

要是贵公司的基本业务模式在发生变化,一半以上的销售额来自一种新的产品交付方式,作为CIO,你会怎么办这就是Intuit公司面临的挑战。

Intuit是一家专业软件厂商,成立于1983年,年收入为31亿美元。集团共有8000名员工,在北美、欧洲、亚洲和澳大利亚有1000余万客户。公司专为小企业会计、报税准备和个人理财提供计算机软件服务,旗下包括Quicken、QuickBooks和TurboTax等知名品牌,总部设在加州。

虽然Intuit的主要收入靠软件套装,但该公司也一直在开发纯网络版的软件即服务(SaaS)产品和连接服务,后者把软件和服务整合到一个方案中。Intuit这么做至关重要,因为竞争对手也在提供SaaS产品。SaaS产品目前在该公司的销售额中占了50%以上。

转变机会

Intuit CIO Ginny Lee在迎接这次挑战中扮演了重要角色。

Lee在1996年加入Intuit,先后任职公司的业务运营副总裁和小企业薪资事业部副总裁。业务运营是该公司最大的服务事业部。去年,Lee被任命为CIO,领导该公司650人的IT部门,近期的目标是把Intuit的SaaS模式提升到一个新的水平。该目标属于公司为了实现客户价值最大化、杜绝浪费而开展的精益IT项目的一部分。

Lee认为:“精益概念是我们公司DNA中的重要组成部分,它对IT部门来说没有什么不同。我们让业务单位加快发展,让职能小组通过流程和技术解决方案,最大限度地提高员工的工作效率。”

Intuit为什么会向SaaS服务转变根据业内专家的估算,鉴于当下的经济形势,Intuit坚持向SaaS迁移的做法是明智的。Gartner公司声称,整个行业的SaaS销售额预计今年会达到80亿美元,增幅超过20%;而此后几年会保持几乎相同的年增长率,会一直增长到2013年。IDC SaaS研究主任Robert Mahowald在近期的一份报告中也写道:“SaaS服务让公司在困难时期比较容易扩张。”

此外,客户对于SaaS产品的满意度取决于网上体验,因为这种产品是在线应用软件,而不是本地安装的应用软件。所以,监测这些网上交易的表现非常重要。这与精益IT的另一条原则相符合,即确保拥有良好的客户体验。冠群公司的企业高级副总裁兼产品总经理Chris Cook表示,SaaS模式还有助于Intuit降低成本,与客户建立更直接的联系。

与客户的这种直接联系也意味着, Intuit可以提供相关服务,并建立网上用户社区。这样做不但让客户能得到帮助,还能降低Intuit的支持成本。Cook解释:“现在Intuit有机会为客户提供意见咨询及其他软件增强功能。客户们也可以自行选择,只要在网上轻松点击,即可升级到功能更丰富的Intuit产品。反过来,这有助于Intuit的客户价值最大化,并拓展业务。”

此外,Lee启动了一些计划和项目,旨在让IT部门促使业务流程自动化,并为客户开发自助服务,从而领先于竞争对手。Lee谨慎地解释,Intuit并没有放弃套装软件业务。相反,Intuit在扩大业务范围,同时提供纯网络版软件和传统的盒装软件。她说:“我们传统的套装软件是过去25年取得辉煌业绩的基石,桌面版的Quicken和QuickBooks仍在客户中发挥重要作用。我们的策略不是非此即彼,而是希望在连接服务领域成为首屈一指的、力求创新的成长型公司。在这个领域,既有软件也有服务――桌面和Web,我们在为客户提供无缝的整体方案。”

为此,Lee采用了顾问Geoffrey Moore开发的一个体系。Moore在其《与达尔文打交道:伟大的公司在进化的每个阶段如何保持创新》一书中说,自由市场经济的运作方式在本质上酷似有机系统。他写道,两者都受制于稀缺资源方面的争夺,导致自然选择,进而带来新的产品和服务,以及对现有产品的改进。Moore补充说,所以,公司要么获得竞争能力,要么面临边缘化的危险。

关注核心

Moore在书中还对公司的“核心”(core)和“周边(context)”作了重要的区分。”核心指公司业务运营中具有的差异化优势,从而让客户在决定采购时偏爱自己的那些方面,周边指除此之外的各个方面。Moore还认为,老牌公司之所以往往输给历史较短、规模较小的竞争对手,主要是因为前者任由自己的资源渐渐从核心沦为周边。

对CIO来说,Lee对Moore的观点很有兴趣似乎很让人惊讶。但是她实际上深谙商业理念。她从斯坦福大学拿到了工商管理硕士学位,拥有布朗大学商业经济学与组织行为和管理学双学士学位。她还在Intuit担任过业务部门的多个领导岗位。

在过去的12个月,Lee及其团队已开始将Moore的体系运用于工作中。她敦促其领导团队采用Moore的象限方格系统,该系统显示了用来评定公司在增值方面所做工作的四个上升区块。Lee解释:“我要求所有***标出他们做的工作,重点确定什么是关键的、什么不是关键的,什么是核心的,什么是周边的。”

团队发现了不是关键核心的工作后,这些工作自动进入周边象限。Lee说:“我们坚决摈弃非增值的周边工作,那样我们就能腾出这些资源,重新投入到增值、关键的核心象限。最终,我们可以把资源分配给真正为客户提供价值的工作中。”这一理念符合精益IT重视客户体验最优化的原则。

改造成“业务部门”

作为精益IT方法的一部分,Lee把传统的IT部门改造成“业务单位”IT部门。按照这种模式,IT领导与各业务单位的代表直接合作,共同关注最重要的业务目标,即是发展、扩张和盈利能力。这意味着IT部门由来自众多业务单位(比如消费者部门和小企业部门)的IT和业务人员组成,这些人员是合作伙伴的关系。

每个团队面向公司的职能和角色都有明确界定,而且必须严格地遵守程序,根据业务增值的多少来确定工作的优先级别。最后,IT部门将资源分配到能够给客户带来最大成效的方面。Lee说:“我把IT部门作为一家公司来运作。为了确保各业务单位(我们的内部客户)与IT部门对于关键优先项目有统一认识,并确保我们提供各自所需的增值服务,业务单位IT部门是不可或缺少的一部分。”

Lee用一个简单的金字塔图形来阐明她的目标。最底层是她所说的基本面(Fundamentals),这包括日常的业务运行工作(见图)。Lee解释:“这些是我们必须搞好的基本IT职能,而且要效率最高、投入最少。这方面必须以尽可能高效的方式来运作。”

Lee目标金字塔的另两层是成功(Succeed)和转变(Transform)。成功是指,她希望Intuit的IT部门与内外客户合作,成为一个增值的业务合作伙伴。Lee还期待IT部门开发一套新的特性及职能组合,帮助Intuit的业务单位扩张和发展。金字塔的第三层是转变,意味着IT能够积极主动地改变客户的一系列工作,比如“我们如何利用自己拥有的数据,帮助客户开源节流”

为了让这一切成为现实,Lee先为Intuit的每个业务单位定义了角色。她的“业务单位”IT***包括产品经理和业务分析员,他们的首要职责是了解各自业务单位的战略,并确定IT部门的目标,随后确保优先项目顺畅执行。然后,Lee希望他们与各自的业务单位之间是“双实线”关系,这意味着他们既要向Lee报告,又要向业务单位的总经理报告。Lee解释:“这样一来,我手下的***密切了解业务单位的战略和优先项目,因为他们与总经理下面的人员直接共事。”

所有项目都经过一套自上而下的严格评估,由总经理和领导团队一起评估。这些评价基于一个首要因素:哪个项目会带来最大的投资回报Lee说:“无论业务单位的成功,还是IT部门的成功,都实行共同所有制和共同问责制。”

利用IT“仪表盘”

为了实现精益IT的目标,Intuit使用了一批成熟可靠的技术工具。其中的主要工具是应用软件性能管理(APM)解决方案。通过结合协同使用的解决方案,Lee让Intuit得以全面了解其客户数百万笔网上交易的情况。

其工作原理如下。解决方案全天候不间断监测最终用户的交易,Lee得以全面了解应用软件的性能,以及自家软件如何服务客户的网上体验。这反过来让她能够实时洞察客户得到什么样的体验,然后把客户交易与基础设施本身对应起来,准确查出任何问题,以便迅速解决,以免变成困扰客户的大问题。与此同时,该解决方案标出各个组件与各项服务之间的依赖关系。Lee的团队基本上可以监测客户体验、应用软件与交易以及基础设施的实际组件。

比如说,如果Lee想知道使用TurboTax的客户具有什么样的体验,可以用监测工具了解情况。现在,她积极主动发现问题,并解决问题。Lee谈到这款解决方案时说:“它对我们而言就好比是煤矿里的金丝雀(注:金丝雀对瓦斯敏感,常被煤矿用来预警瓦斯泄漏)。”

解决方案还让Intuit的IT团队能实时衡量业务指标,通常是由客户互动提供的。做到这点的第一步是,先把应用软件与Intuit的基础设施对应起来,这可以得出“用户体验仪表板”,不但显示所有活动用户总体的体验,还显示了每个用户的体验。

仪表板显示了Lee所谓的客户体验的“关键时刻”(key moments of truth),比如用户登录。这听上去也许很简单,但对于一次成功的登录来说,几项活动必须同时进行:要允许用户登录,要验证账户和密码,还要让用户的不同登录与众多Intuit产品相匹配。

仪表板还显示了业务衡量指标。每个流程都直接显示在仪表板上,标以红色、**或绿色的信号。然后,IT人员可深入分析,查看底层基础设施的情况。Lee说:“这就是把应用软件与基础设施对应起来的意思。”

Lee举例说:“每当用户与我们‘会话’时,我们希望自始至终提供良好的客户体验,就算只有一个用户在使用我们的产品也是如此。如果数十万、甚至数百万的用户在使用这个产品,我们更要做好服务。”

Intuit的IT团队与业务单位通力合作,旨在确定“为了实现我们的目标而需要开展的最佳项目。”比如说部署监测工具。那样他们就能为客户在挑选、购买及使用Intuit的产品时,主动提供良好的客户体验。Lee说:“我们这么做都是出于本能。我们需要以最低的成本,为我们的内外客户提供最大化的价值。”

链接

CIO的五个成功经验

Intuit的CIO Ginny Lee运作IT部门的方式尤如同开公司,这意味着Lee在不断寻求新方法,以便为内外客户增加价值。这让Intuit有别于竞争对手,以及确保IT团队中有合适的人员。

保持专注。“绝对有必要知道何种IT方法能起到重要作用,并为公司和客户带来最大化的价值,然后绝对关注这些方法。”

规划工作。“确保你所做的工作能让贵公司在增值方面有别于竞争对手。明确什么是‘核心’即关键工作,什么是‘周边’即其余的各项工作。”

态度坚决。“对于那些非增值或没有差异化的方面,态度一定要坚决否定。之后,CIO才可能把资源重新分配,专注到能为客户带来差异化价值的方面。”

关键在人。“确保开除不合适的人,招进合适的人,并且安排在合适的岗位。要让他们定一个远期目标,激励他们实现目标。”

积极转变。“借助精益IT,CIO就能把节省下来的资金,重新分配到创新项目中。当用户得到的体验优于竞争对手时,你就会赢得客户的忠诚和信任。”

链接

外包商的精益IT之路

当形势变得艰难时,外包商TechTeam走上了精益道路。

其他公司可能在等待艰难的经济时期过去,但TechTeam Global公司却不这样。这家年收入达26亿美元的外包公司正在开展一个为期三年的大胆项目,希望既能扩大市场知名度,又能加强与客户之间的关系。为了推动这个项目,总部设在密歇根州南菲尔德的TechTeam采用了同样大胆的精益方法。TechTeam公司的总裁兼CEO Gary Cotshott说:“我们只要牢牢抓住可以提高效率的机会。这时候,精益方法就有了用武之地。”

TechTeam完全有资本满足于现状。这家公司成立已有30余年,提供30多门语言的IT支持,在15个国家直接设有办事处。但Cotshott不是满足于现状的人。他的三年计划内容包括:为该公司的基础设施增添新功能、扩大业务覆盖范围,以及提高TechTeam在全球市场的知名度。

Cotshott及其同仁在全公司利用精益方法,改善提供给客户的服务,并提高效率,帮助公司致力于实现三年计划的目标。这方面的一个重要部分是精益IT,以便对帮助IT为公司带来价值的流程和系统进行优化,并使之自动化。Cotshott说:“在过去的18个月,精益IT在TechTeam Global内部得到了非常积极的发展。”

TechTeam的CIO Armin Pressler表示,他的IT部门从全局的视角来看待精益方法。Pressler解释:“我们与自己的业务目标保持完全一致。”由于他的团队实际上服务于两组客户:外部客户和TechTeam的内部员工,“精益IT对公司总体价值来说绝对很重要。”Pressler补充说。

TechTeam执迷于用Cotshott所说的“全球工厂”模式来开展业务。这意味着各地部署一种标准化的单一接触点(SPOC)模式,从北美、欧洲、亚太区以及不久后的拉美等地提供服务。因确保了全球一致性,加上集成了自助服务、服务台、远程基础设施管理和现场支持等解决方案,结果公司提高了效率,而且节省了成本。

Cotshott在2008年年初进入TechTeam公司,他着手的首批项目之一就是部署一批IT管理解决方案。他表示,这是打下了基于信息技术基础设施库(ITIL)的牢固基础,还建成了集成的服务交付平台,该公司可以在全球统一部署。Cotshott表示,此外,拥有成熟可靠、功能丰富的服务交付平台,这让TechTeam可以提供满意度明显高于竞争对手的客户体验。

Cotshott的说法得到了独立的客户满意度研究机构的支持。在2009年的《知名基础设施管理外包服务商调查》中,Orbys咨询公司的《外包黑皮书》将TechTeam列为大中型企业客户求助台外包方面的全球第一位,列为中型企业客户总体IT基础设施外包方面的全球第一位。

如今,TechTeam公司的1000名接线员、分析员和技术员在使用IT技术来支持客户。TechTeam的全球客户服务管理副总裁Bob Gumber说:“我们正在走全球化道路,尽可能在各方面进行标准化。我们还始终致力于工作流程优化、提高首次来电解决率以及降低平均处理时间、避免问题扩大,这些做法提高了效率和效果。这意味着IT为我们的客户提供了更高的价值、提高了客户满意度,最终增强盈利能力。”

这就是精益IT的魅力。

CIO IT团队***考虑金字塔结构的目标。下面两层是不断提高效率和效果的目标。顶层则重点表明了客户们在将来的需求。

世界级的IT组织

转变、预测将来的需要

成功、满足客户的需求

基本面、满足基本的业务要求

Intuit的IT目标金字塔

一朵好云是怎样炼成的

云计算市场在这几年可以说是井喷式增长,各种围绕云的新技术、新公司如雨后春笋般冒头,市场不断出现各种不同的声音和探讨,每周都有各种新闻层出不穷,有新产品发布,有公司拿到投资,当然也有系统大规模宕机等秒删新闻出现。

客户呢也开始逐步从被动走向了前台,若干年前客户在说做一个项目要有云的标题那会只是追求时髦,现在更多的客户从不同的角度已经开始了践行和尝试,有业务驱动的,有公司转型的,有实验测试的,有大规模推广的。众多的机会和想法出现是一个好的事情,给不同层级的公司都提供了展示的机会和发出声音的舞台,这种芸芸众生已经彻底改变了过去IOE等大型企业级外企市场所形成的稳定的平衡。但是打破这种平衡新的平衡出现了吗?其实并没有因为大家都在不断摸索和尝试。本人也在这个浪潮中观察、支持到亲自参与。我更想分享一下在这波云的大潮来临之时,或者说变革的机遇到来之时。什么样的趋势和潮流是适应客户的,是可以真正和他们的业务融合在一起再次形成稳定的。传统企业型客户的IT 毕竟不是实验室,他们不可能拥有互联网行业的人力资源和不断变化的业务前端,也不可能拥有运营商运行的广大基础设施,对于他们来讲构造一朵云的核心在于和业务整合,可以从创新,交付体验,成本,稳定,支持未来转型等方面提供支持。这个过程不仅仅对于客户是一种历练对于提供服务的服务商更是一种考验,就像炼钢一样,经过了一步步的过程和工艺才能成为合格的产品。当然我本人的职位和工作范围更多的让我的视角关注客户私有云和行业云的建设与运维即:如何帮助客户炼成一朵好云。

你的组织和业务ready 要去云了吗?

我们从私有云建设说起,在几年前如果我们和客户交流云计算,客户更多的关注是虚拟化,当时的主要工作就让客户接受虚拟化,所以只要能够虚拟化所有项目都可以冠以一个云的头衔。随着这几年大型公有云的成熟落地体验和云技术的普及,客户已经慢慢的接受了云不仅仅是虚拟化,云是面向服务和交付的一个体系,这里既包含了最终用户也就是业务部门的自助服务获取,也包括从网络连接到服务质量保证的一体化运维,甚至在某些转型客户要求的行业云中还包括运营到销售管理的业务模式。这种真正的云对于客户来讲投资相当巨大,所以首先要判断是否需要做一个真正的私有云(行业云),还是直接购买公有云或者别人的行业云服务。判断的标准一方面从定制性考虑,一方面从安全性角度考虑,公有云服务就像在食堂吃饭,饭的种类虽然很多但是不见得可口和适合自己,自己某些企业特性的需求对基础架构或者中间层有很多要求,那只能自己搭建云的服务。当然追求极致数据安全的公司更为需要。另外一个方面就是客户的应用是否需要上云,从逻辑的角度讲,客户的应用一般会分为不可云化应用、可云化应用、适合云化应用和原生云应用。这几种类别的判断标准不仅仅是技术上的虚拟化、分布式存储、融合计算。还包括了应用的d性需求,业务交付需求,变化需求,以及对外围API 和其他应用的交互需求等。对于构建私有云的客户而言,d性的资源池也就是底层平台不可能是随意部署和加载的,资源池是经过设计采购、租赁等一定周期才可以部署到位的,所以构建私有云的重要目的是保证自己建设的池子的最佳投入产出比,也就是运行的应用和负载可以最大化合理的利用现有资源池资源,保证一定的冗余,在大量业务下线后,能够对资源池做适度的下电关机实现适度的缩减。从应用的角度需要看不同类别应用完全可以采用不同的手段来实现,当然成本和技术可能都会大大的不同。原生云应用一般都是企业目前正在尝试的新业务产品和方向,这种类型应用如果在数据信息安全允许的范围内,最适合放到公有云或者通过混合云来实现。当然更为广泛的适合云化应用和可云化应用才是目前企业的主流,针对这种应用类型,在考虑构建云的时候就需要应用开发部门和团队的介入,仅仅提供虚拟机、存储服务器的纯粹的IAAS或者虚拟化云平台并不能改善业务的交付模式,所以从交付模式入手,能否将应用的加载完全交给业务部门来选择,让他们根据业务的变换来选择启动或者关闭从应用到底层基础设施的服务,这是向云化部门迈向的重大一步。这个过程需要应用部门和基础架构部门配合在一起,共同制定d性方案,能够确保d的出去收的回来。这个过程就叫做服务的编排。

从我们的经验来看要想应用平稳的实现云化,有两大工作要做,第一步叫做搭架子,第二部叫做上云。当然我们要放到一个全生命周期的角度去构造,只有不忘初心我们才知道我们无论走多远做多少尝试都可以走到终点。下面的图主要向大家展示了云平台建设的过程以及所需要的服务。

现在先说说搭架子,搭架子就是云计算的规划和评估,设计整个云服务的交付模式,这其中包括需要考虑1应用云化的路线图,因为建设云平台,应用改造,迁移,测试,扩容等不会一蹴而就一定是通过一定的周期来实现的。2 对资源和工具要求的规范化,如果在企业中都是标准的当然完全可以使用公有云甚至混合云,但是不同的企业由于不同的应用发展,因为时间的日积月累导致部署架构和应用所使用的中间件数据库等五花八门,七国八制,这在建设云平台的过程中就需要考虑准备整合版本逐步统一,这样才能为后面的服务编排带来可能。3运维流程及SLA的规范化,云是一个容器,将多种应用架构于其中,通过服务交付自动化和自助的交给了业务最终部门和用户,交付什么,交付的流程和规范特别是SLA 要在一开始就设计出来,因为这个将直接影响后面的技术体系布局和运维管理服务的成本加载。4最后就是云环境下持续交付的流程,这中间要考虑到应用的扩容d性及业务连续性等一系列问题。做到了这些步骤,建设一个完善的云体系至少不会很盲从和缺乏方向。但是仅仅有这些,这个架子还没有完全搭建起来,更为重要的一步就是服务编排和资源池的设计。服务的编排是从应用角度看待的,是将应用组合根据需要通过自动的流程启动或者关闭,对于基础架构部分完全融入到应用的自动化运作之中。服务编排的设计非常重要,需要了解应用和懂得基础架构甚至于后期建设云管理平台的人员一起合作,这个过程是将项目制的应用软件和底层架构整合的标准化和模板化,最终实现所谓的workflow。通过这部分设计就可以知道服务所需要编排哪些自动化的模板和对底层架构所需要的基础资源以及相关的技术体系。

资源池设计,说到这部分不得不谈谈OpenStack, OpenStack 算是一个非常好的工具可以帮助客户把整个基础架构底层穿连起来包括计算、存储、网络,不断撬动这 IOE、VMware 厂家所固守的商业产品阵地,客户完全可以通过OpenStack 展开一段开源的云计算之旅,但是既然是开源产品和体系就一定具备开源产品的特点和掣肘,缺乏商业产品的稳定成熟、缺乏明确的产品演进路线,缺乏配套的服务都是客户需要面对的问题,特别是稳定性及运维等。从目前的经验看,OpenStack 更像是乐高玩具,不同的技术人员在客户处部署和实施的方式可能都不一样,所以软件和硬件的耦合性就变的非常重要。客户在设计资源池的时候什么样的硬件配置,网络、存储服务器加上软件可能会产生数量巨大的不同排列组合,由于硬件的一些耦合性和特点,遇到问题和故障就变的非常频繁,客户无法当小白鼠反复试验,所以Reference architecture 就变的非常重要了,也就是通过试验和项目已经总结了哪些品牌的配置的机器组合在一起时是可以满足要求的。当然除了机器配置外,标准化的设计也为客户在实施项目中提供了指导,大大降低了实施的时间。客户只需要通过POC 来验证功能的合理性。

有了体系和架子,基本上一个如何做一个云就算想清楚了,具体怎么做有很多种方式了,可以自己DIY 动手从头做,也可以提出需求去购买管理私有云和托管私有云。当然成本与交付时间以及后期的运维的ROI 是可以作为评判的标准的。当然有些人觉得这个好复杂,我就找个OpenStack 厂家搭个池子或者用VMware,就可以有虚机、存储、网络提供了,我有了基础的IaaS 我已经云了,这么做当然可以,但是做多大规模,做出来仅仅供应虚机是不是业务部门要的,如何管理与交付,后续项目还有没有成长性都无法回避。所以做不做云就像前面说的这是业务模式的转变,还有组织也要随之变化,例如增加一些角色如服务交付专员,编排设计架构师等。

云管理平台的重要性

云管理平台Cloud Management Platform 实际上一个非常重要的平台,这个不光在Gartner上面有单独的魔力象限,在我们建设全生命期上也可以看到这是实际是整个云建设的一个重要的落脚点。当然多说一句Gartner的魔力象限,其实在国内目前云管理平台,客户更倾向于本地化与定制化,这是因为云管理平台是客户管理灵魂的体现,如何和自身管理相结合,大量的客户化不可避免,所以云管理平台的竞争是最激烈的。

云管理平台可以说从发展的历史看也非常悠久了,早在前几年,当客户发现仅仅通过VCenter 已经无法实现面向客户端的自动化交付和应对交付流程要求的时候云管理平台就应用而生了。现在的云管理平台已经是一个横纵的汇合点一个接入的核心。向下兼容和管理基础架构系统,包括多种资源池,VMware,KVM,Power的等等,KVM体系资源池因为有了OpenStack所以基本上是调用OpenStack实现,VMware则是VCenter,Power是PowerVC,通过和底层的管理软件互动,云管理平台可以看到不同的资源池,同时更重要的是在资源池之上构建服务层,也就是将不同的资源组织成服务通过编排交付给客户。这是云管理平台的向下维度,向上的维度则是云管理平台和PaaS层应用层的整合,目前的可云化应用和适合云化应用多数使用传统中间件和数据库,所以云管理平台主要将在上部分内容讲的云化的软件中间件模板和底层的虚机模板,通过服务编排整合,最后通过服务的方式直接交付给客户应用系统而不仅仅是底层资源,这部分是目前云管理平台发展的热门,特别是针对企业客户。当然在今天对于应用的承接也还有Docker的模式,所以云管理平台加载Docker服务就可以为客户提供原生云应用的部署环境和能力。云管理平台的价值要完全实现还需要横向左右的配合,也就是监控运维和混合云接口。过去所建立的云平台一般多带有实验性质,很多管理流程特别是ITIL 并没有加载其中,目前建设的云管理平台,大家一方面希望提供的监控过程是一体化的,能够帮助自身了解基础资源池到虚机甚至于到中间件的各种性能和状态,也希望提供编排的规则可以实现自动的启动和关闭从而彻底实现云的自动化d性价值,这就需要云管理和监控系统进行完善的整合或者提供部分的功能。对于混合云来说,虽然部署方式、数据传输、安全依然是需要面对和思考的问题,但是通过云管理平台可以管理远端公有云自身购买的环境,实现一体化的管理已经是不少云管理平台逐步实现的功能,下一步必然是跨云的部署监控以及计费等。所以作为云最重要的组件之一,云管理平台对服务业务交互和交付起到非常大的作用,这可不是仅仅一个OpenStack的汉化Horizon可以实现的。当然做云管理平台这部分的软件厂家也比较多,因为不会影响生产的底层,所以只是存在客户化实施能力和好用不好用的问题。当然别小看这个客户化和好用不好用,其中一个点叫做用户的易用性设计,举个例子,因为OpenStack本身的设计有一个问题就是他的用户群是虚拟化的管理人员,而云管理平台是面向真正用户而设计的软件系统。这个跟OpenStack是两个设计思路也是两个方向。

运维管理

运维管理在客户进入云的世界后也发生了翻天覆地的变换,过去客户业务系统相对隔离,基本都保持HA 等高可用形式,稳定的主机、网络、存储,通过API 和端口可以很好的自动发现和监控。现在的云管理平台更多的采用的是SDE 的架构在这种架构之下,硬件相对标准化和简化,如X86服务器,更像硬件产品家电化,软件在 *** 控硬件产品的过程中变的更加重要起来,从支持虚拟机的核心到存储到网络,都靠软件来实现,这必然让客户对下要和 *** 作系统,甚至内核参数打交道,横向要兼顾网络、存储、计算的整体健康状况,比如我们碰到过得一个案例在一个项目中遇到虚拟机丢包,长连接会卡中,OPENSTACK 中网卡,追踪到Redhat自带的的Intel网卡驱动版本过低的问题,最后升级版本解决问题。这些还不算,还要考虑到和硬件的匹配以及兼容度的问题,我们也在项目中遇到反复宕机最后锁定是硬件微码等问题的案例。

当然有的人会说我们构造的云平台就应该是HA高可用的,是的,在云平台的架构设计以及功能的角度这是非常重要的,我们必须要在设计时考虑各个层级的高可用,从存储、到OPENSTACK到云管理平台,各个级别的高可用在通过监控软件穿连起来就实现了整个平台的稳定。而且在实际生产过程中VM支持在线迁移很重要。比如某资源池支持全部物理机微码升级,但是已经有很多生产的关键业务在运行,为了达到不影响业务的物理机升级,在云平台部分,由于支持高可用,停止掉一台物理机的服务不会影响云平台的运行,所以可以迭代升级。在计算节点,由于支持VM在线迁移,所以也可以迭代升级。当然这些底层运维场景只是一部分,还有一部分是业务和中间件的整合,我们也有碰到若干虚拟机只有一台反复丢包的情况,最后排查就是应用的问题。

所以云服务是一个大容器,这个大容器不能说是高压锅吧,但是压力确实不小,应用于今天的云运维服务,整个工具链系统也在不断演进,目前我们云运维团队常使用的工具就有开源和商用的两种,其中开源的有saltstack,nagios,elk,lpar2rrd。还有itm,powershellcli,最后还得自己写脚本。如果客户要自己运行好云,一方面要希望云管理平台和这些监控工具集合,另外一方面也要自己投入时间学习和研究。云运维和传统运维综合相比,1云运维不仅仅关注硬件和物理层,而更关注整体系统和应用层,2云运维更需要软件及系统的自动化部署,3 通过生命周期形式来管理应用程序,如自动软件更新。4 负载均和和容量自动扩展保持最佳的私有云投入产出比。5降低运维成本。

所以如果从目前构造的项目来看,以VMware为底层打造的云平台,客户更多的关心应用层的问题。以OPENSTACK 开源打造的云平台,客户要更多的依赖服务厂家,要不就自己人和投入资源整合工具链逐步实现运维,目前更潮流的模式是给客户提供管理云服务。管理云服务就是管家型云服务,专业的人干专业的事情。管家云服务通过提供专业的管理运维工具或者管理服务,帮助客户维护和运营一个稳定OpenStack 基础架构。这种业务可以将客户彻底解放,而且专业的团队有专业的知识库和人员可以分享。当然这种业务模式所牺牲的就是完全的客户化,因为客户的硬件体系甚至软件,特别是OpenStack 必须要运维厂家实施部署方能够进行友好的管理,而且管理服务厂家必须通过远程监控运维以实现一定的服务级别和响应。

云安全

云计算通过资源池的模式将数据进行集中管控,比传统分布在大量终端上的数据更安全。由于数据的集中,使得安全审计、安全评估、安全运维等行为更加简单易行,同时更容易实现系统容错、高可用性和冗余及灾备恢复,但是传统的IT安全威胁种类依然存在,因此传统的安全防护方案依然可以发挥一定的作用。

云平台的安全保障可以分为管理和技术两个层面。首先,在技术方面,需要按照分层的思想,基于安全域的划分,从物理基础设施、虚拟化层、网络、系统、应用、数据等层面进行综合防护;其次,在管理方面,应对云平台、云服务、云数据的整个生命周期、安全事件、运行维护和监测、度量和评价进行管理。考虑云计算所带来的变化、风险,从保障系统整体安全出发,构建一朵安全的云。除了需要考虑基础设施安全、虚拟化层安全、虚拟网络边界安全、主机安全、应用安全、数据保密和防泄露之外,还要关注安全运维管理、法律和合规等方面的需求。

目前我们所实施的项目多数让客户在传统网络和安全防护的层面,在加入多应用和虚拟化层的安全控制,因为现在大量使用开源软件,特别是应用软件,漏洞扫描补丁管理一定要在业务上线之前,而且在云计算中的物理金属逻辑在上线加入云平台后也需要同步安装防护软件,以避免其在互联网端裸奔。总体看云计算的安全问题是无处不在而且严峻的,最好的方法,就是安全设备可以如同存储设备一样,形成池化的资源池,在用户申请云服务器时,与计算资源、存储资源一起按需分配给用户。目前,在公有云市场,已经有云服务提供商将安全作为基本属性交付给用户,在用户购买云计算服务时,用户得到的是安全的ECS、CDN、RDS和OSS。相信不久之后,各种池化的安全资源也会在私有云环境中得到运用,到时候安全也将成为搭建云服务的众多乐高积木中的一块,任你选择和支配,它只局限于你的保障需求和想象力。

总结

以上聊了这么多其实就是和大家分享一下这么多年做项目下来的一些想法。一朵好云建设就像打造一件工程作品,一开始就要设计好图纸,有了图纸可以选择自己来或者直接购买合适的云服务,因为目前市场上竞争激烈,也没有什么明确的规范,所以客户选择是非常困难的。

我个人的建议是分类去看,云管理和底层分开来看。云管理可以一步一步通过客户化和项目最终达到效果,但是底层呢一旦选择再次更换就会变的非常消耗时间和成本。同时底层和运维的匹配度也是非常重要,一个无法管理和不便于监控管理的底层无异于是一个彻底的黑洞。所以可以提供良好管理甚至于管理工具的底层将变得很有价值。谈完这些最后其实考察的就是团队了,一个厂家的云建设团队其实也很难做到全能,因为技能水平,客户现场复杂度,产品成熟度等各种差异化条件,你很难让一个原来做木工的还要能做好瓦工,当然OpenStack 的实施服务要求,已经在往这个方向发展了,要能够综合解决问题,同时服务和支持的体系也很重要,其实云化的前期发生问题和出现问题非常正常,你用一堆开放相对廉价的软件和硬件堆出了一个商业用的高可用环境,无论从压力和能力角度,故障和问题都是常态,所以认识到这个问题,及早构建支持服务团队或者购买相关服务可以让客户的使用感受大幅度提升。个人认为SDE 所带来的变化将是软件更加复杂和开放,商业模式也将逐步过渡到以服务为主,通过个别版本想一统天下的时代在慢慢的消亡,所以购买一朵云无论是公有云还是私有云最核心的是购买的服务,最终用户购买使用了服务,运营方购买了厂家的服务,所以管理型私有云在开源开放体系的架构中将会全面的发展。

以上就是关于互联网时代的网络自动化运维全部的内容,包括:互联网时代的网络自动化运维、“ITIL”是什么意思、ITIL的目标是什么等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/9865441.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-02
下一篇 2023-05-02

发表评论

登录后才能评论

评论列表(0条)

保存