精华内容
下载资源
问答
  • 开发运维一体化

    千次阅读 2018-05-21 22:11:26
    今天我们大家一起来回顾一下,企业应用的开发运维模式是怎么个样子? 无论是基于应用开发平台开发好的业务应用(一般为java类应用,程序war包的形式),亦或是...我们现在讲开发运维一体化,是因为越来越多的项目要...

    今天我们大家一起来回顾一下,企业应用的开发运维模式是怎么个样子?

    无论是基于应用开发平台开发好的业务应用(一般为java类应用,程序war包的形式),亦或是基于服务治理平台开发好的微服务应用,针对这些应用,我们该如何运维?

    运维的条件:高配的物理机?虚拟化技术?Docker容器?持续构建?缩容扩容?自动化测试?监控预警?APM?KPI?。。。

    我们现在讲开发运维一体化,是因为越来越多的项目要求CI/CD等可持续交付及持续运营的能力。

    开发者中心为开发者提供了资源管理、持续集成、持续交付、容器服务、镜像仓库等应用基础服务,同时为应用的微服务架构落地提供完备的支撑,结合DevOps的理念,通过提供自动化运维、日志管理、中间件服务等功能,帮助开发及运维人员降低产品研发迭代过程中的负担。

     

    核心功能:

    1.资源管理:以资源池的方式进行计算节点管理,自由添加自有主机,进行智能化的资源调度与分配。

    2.容器服务:以应用为中心,简化上云过程,为应用提供扩容、缩容、升级、回滚等功能,支持服务发现、负载均衡。

    3.DevOps:以可视化的方式实现应用的集成、测试、发布自动化,并提供在线控制台及日志,进行故障分析与排查。

    4.持续交付:以Docker镜像为应用交付载体,一次构建,到处运行,平台自动生成子域名,让应用自由接入。

    5.镜像仓库:共享容器生态,尽情无限探索,镜像仓库中的应用开箱即用,按心情随需部署各类应用软件。

    6.微服务:全面支持微服务架构,只要你敢拆,我就敢部署,结合服务发现、配置管理支撑大规模微服务的运行。

    7.自动化运维:通过全面的监控报警、日志收集、健康检查、服务自愈、泛域名解析及应用链路管理等,减轻运维负担。

    7.日志管理:平台能够解决海量日志处理难题,数据加密存储。上云应用,无需配置,即可随心查看各种业务日志。

    8.运营分析:平台能够自动统计应用的访问量情况、访客地域分布、业务的响应时间,结合运营数据进行业务发展决策。

    9.中间件服务:平台提供主流的缓存、数据库、消息等中间件,开发者可按需选用支撑服务,方便快速搭建开发测试环境。

     

     

    产品优势

    开发者中心提供了对应用开发态和运行态的全面支持,可以看成是开发者的云、运维人员的云、DevOps的云、行业领域的云、支持创新的云。 它是一个应用全生命周期管理的平台,底层基于容器技术(Docker),全新的技术模式正在快速改变着公司和用户创建、发布和运行分布式应用的方式。 DevOps的理念使得软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发、运维和运营工作必须紧密合作。 开发者中心将DevOps理念融入其中,并致力于打造企业应用开发运维一站式服务。

     

     

    应用场景

    1.互联网应用可通过平台一键部署,应用的开发、测试、灰度、生产环境自由切换、统一管理。

    2.加速互联网应用的持续交付、快速迭代,赋能企业应用交付能力、降低应用交付成本。

    3.在镜像仓库发现你想要的应用,Jenkins、Sonar、WordPress等应有尽有,在云上畅快体验应用的各种功能。

    4.传统企业服务多为单体架构,通过平台可轻松实现向微服务架构的平滑转换。

    5.移动APP流量峰值随时产生,平台具备弹性计算能力,能够支撑高并发的访问。

    6.研发过程中需要各种测试库,通过平台可选用所需中间件,快速搭建自己的测试环境。

    7.助力IoT,基于平台构筑大数据系统,智能硬件数据可自由收集,让硬件更智能。

     

     

     

     

     

    展开全文
  • DevOps开发运维一体化
  • 开发运维一体化(DevOps)验证.zip
  • 开发运维一体化(DevOps)验证.doc
  • 开发运维一体化(devops)能力成熟度模型
  • 程序猿如何进化——云上的开发运维一体化.pdf
  • 本次演讲将包括以下几部分:什么是DevOpsDevOps能力融合四大核心实践开发运维一体化PaaS平台建设四要素分享之前,先看几个数字。这些是来自亚马逊Apollo平台的数据。过去一年中亚马逊推送了5000万个部署,每分钟达到...
  • 双模云管平台助力银行实现开发运维一体化.pdf
  • 江西省水资源管理系统开发运维一体化云服务平台的研究与实现.pdf
  • 开发运维一体化(DevOps)两岸共通标准研究报告: 云计算作为信息技术领域的一种重大创新应用模式,是战略性新兴产业的重要组成部分,为推动两岸云计算标准融合与共通,促进两岸云计算产业合作与发展的理念,自 2013...
  • 1、敏捷开发管理(需求管理、计划管理、过程管理) 2、持续集成/交付(配置管理、构建与集成、测试管理、部署与发布管理、环境管理、数据管理、度量与反馈) 3、技术运营(监控服务、数据服务、容量服务、连续性...
  • 存档日期:2019年5月14日 | 首次发布:2011年3月8日... 本文介绍了可用于敏捷软件产品开发生命周期的各种虚拟技术。 此内容不再被更新或维护。 全文以PDF格式“按原样”提供。 随着技术的飞速发展,某些内容,步...

    存档日期:2019年5月14日 | 首次发布:2011年3月8日

    虚拟化是一种现代方法,可以增强系统共享系统资源的能力,以确保预配可以轻松满足业务需求。 敏捷开发可帮助我们随着软件开发中不断变化的业务和市场需求来确定利益相关者的意见。 本文介绍了可用于敏捷软件产品开发生命周期的各种虚拟化技术。

    此内容不再被更新或维护。 全文以PDF格式“按原样”提供。 随着技术的飞速发展,某些内容,步骤或插图可能已更改。

    翻译自: https://www.ibm.com/developerworks/aix/library/au-virtualizationagile/index.html

    展开全文
  • DevOps 体系是从原始运维一步步走过来的,原始运维好比是本,有了本进而想继续提升效率、减少出错、优化流程,就发展到了 DevOps,AIOps……首先,运维的业务职能规范后形成章程、纲领,在互联网快速发展的特点下,...
    3e2d7b600ff039ae2ac5a6e4d83fad57.gif a828dba51fe5cb2ec971b585c2d3d658.png

    前记

    体系就像是一顶帽子,是对 DevOps 运维的一个深度总结,写一下工作中的感悟,希望对你有所启迪。 DevOps 体系是从原始运维一步步走过来的,原始运维好比是本,有了本进而想继续提升效率、减少出错、优化流程,就发展到了 DevOps,AIOps…… 首先,运维的业务职能规范后形成章程、纲领,在互联网快速发展的特点下,形成了一套应对”快”和”变”的体系,并不停的迭代升级,工作这些年,体会到千象背后是有恒道的,运维工作一直围绕高 SLA 和低成本的业务目标运转着,只是工具在围绕着体系变来变去。从开发的角度理解,运维体系就像是算法,实现算法的语言就像是工具,DevOps 就是工具的升级。 工具的本质其实是一个基础支撑,有了这个支撑,一系列目标的实现才更科学、高效,简单示意如下。 35aa4882294b3cab31b0a0ca09cb344c.png 原始阶段,运维工程师与各部门无数的磨合、探索下,慢慢形成了最初的体系,其无形的规范着运维的工作和注意事项,工程师通过这个纲领开展日常工作并保障业务的健康发展,这个阶段可以说是制度为王、制度规范,没有系统的运维平台,有的只是零散的一些大小工具,各种事物基本靠人工、靠制度、靠约束,虽是原始阶段,但也是运维最真实的样子,忙碌而又忙碌,效率总跟不上需求,制度总跟不上执行,与开发的协作总难同一频道,需要大量的运维人力。 再向后发展,为了提高效率的同时解决与开发间的沟通协作问题,提出了 DevOps,大家开始做自动化、做 DevOps 文化,这个自动化其本质是把运维体系落在一个到多个系统上,通过自动化系统来提高工作效率,同时用系统来实现制度,开发和运维都在一个系统上协作,遵守同样的规则,协作上也高效多了,这个阶段到了技术为王、平台规范,市场上出现了运维开发,出现了 SRE,各种问题得到了有效的解决,当然解决的程度取决 DevOps 系统做的优劣,这个就参差不齐了,但出现了这个发展方向。 再向后发展,行业领头羊提出要进一步减少人工参与,用机器自动化替换人工自动化,进而出现了 AIOps。 细心观察,从原始运维向 DevOps 的演进过程,就是越来越注重技术解决问题的过程,人员需要越来越少,能用技术替代的岗位慢慢被替代,随着自动化平台的成熟稳定,理论上理想的终极状态可能只留”运维平台+业务运维“,其他运维转岗业务运维,业务运维转岗技术运营。 那么我们如何思考设计一套 DevOps 运维服务体系呢?总结下来,一个最小的模型为定业务规范、建工作制度、搭 DevOps 系统,以此为最小单元循环往复、迭代升级。

    一、定业务规范

    先讲个美国人与中国人种地的事儿,美国人建立农场,把种地标准化流程化后,引入工具,几个人种几百亩地收成高、成本低反而不累,中国人每个人几亩地各自作业,收成低、成本高反而都很累。 做运维我感觉也是这个道理,想要批量化、高效率的作业就要规范化,制定各种标准形成规范,如果每个服务各自为战,就会出现乌泱泱一群人确实忙的脚不离地儿,但就是不出活儿。 那么我们通过 DevOps 要批量管理哪些东西呢,集中一下大概就是资源、服务、规范三类,资源包括像服务器、网络设备、负载均衡、证书、域名、代码、容器等,服务包括像围绕运维提供的服务监控告警、CI/CD、日志分析、服务预案、配置管理等,规范包括像流程、资源、服务的各种标准化等,简单示意如下。 79609849b734e0947eec1ad3537b2f51.png 所以规范是整个 DevOps 体系建设里非常重要的一环,每个规范也对应了一些最佳实践原则,整理了一些运维中的规范如下:1、 变更规范
    • 上线变更:代码上线、回滚、扩缩容;
    • 配置变更:系统配置、应用配置;
    • 网络变更:网络割接、设备更换;
    • 其它变更:流量调度、服务切换、服务下线…
    原则:
    1. 制定变更审核流程;
    2. 制定变更相关方通知(群、邮件);
    3. 制定变更回滚策略;
    4. 遵循测试、灰度、全量上线的规则;
    5. 下线变更要将服务器依赖处理干净,比如说挂着vip、有域名解析。
    2、容灾规范
    • 服务灾备:多机器、多机房;
    • 数据灾备:多备份、异地备份;
    • 网络灾备:多线路、多设备;
    原则:
    1. 自动切换 好于 手动切换;
    2. 无状态 好于 有状态;
    3. 热备 好于 冷备;
    4. 多机房 好于 单机房。
    3、容量规范
    • 系统容量:木桶原理计算系统的全链路容量、用量、余量;
    • 模块容量:模块的容量、用量、余量;
    • 机房容量:分机房的容量、用量、余量;
    • 单机容量:用于反向计算机房、模块容量;
    原则:
    1. 制定模块单机容量指标(比如QPS、连接数、在线用户数等);
    2. 容量要考虑下行(读)、上行(写),考虑存储增量;
    3. 计算当前模块总容量,收集当前的用量,并对比容量计算余量;
    4. 系统总容量可以根据木桶原理,找到短板模块后,反向计算出来。
    4、巡检规范
    • 用户核心指标;
    • 服务核心指标;
    • 基础资源指标:服务器;
    • 依赖资源指标:依赖db、依赖接口;
    • 自动化巡检报告;
    • 值班oncall安排;
    原则:
    1. DashBoard核心在于收敛、舍得;
    2. 自动化巡检的必要性在于异常侦测,预防故障。
    5、告警规范
    • 基础监控:CPU、内存、网络、IO;
    • 应用监控:进程、端口;
    • 业务监控:日志、业务埋点;
    • 依赖监控:数据库、依赖接口……
    原则:
    1. 核心监控收敛成告警,并对告警进行分级,备注告警影响;
    2. 核心监控形成可排查问题的DashBoard;
    3. 告警的价值在于实时发现故障。
    6、预案规范
    • 线路切换:移动、电信、联通线路切换;
    • 机房切换:不同机房切换;
    • 机器切换:机器故障时进行摘除;
    • 服务降级:无法切换时,降低标准继续服务;
    • 数据库切换:主从切换、读写切换;
    • 网络切换:主备线路切换、链路切换;
    原则:
    1. 域名切换 好于 更换IP;
    2. 自动摘除 好于 手动操作;
    3. 自动切换 好于 手动切换;
    4. 考虑好雪崩事宜。
    7、故障管理规范
    • 服务分级:确定各服务用户角度的影响;
    • 故障定级:制定故障定级标准;
    • 制定故障通知、处理规范;
    • 制定故障复盘,改进措施按时保量完成的规范;
    原则:
    1. 拥抱故障,同类故障不能重复发生。
    8、权限安全规范
    • 开发、运维、临时权限;
    • 安全上符合安全审计标准。
    9、文档、工具规范
    • 统一共享知识文档;
    • 统一共享各种脚本工具;
    原则:
    1. 理想的情况是“一站式运维平台”,一个平台涵盖所有工具操作。
    10、标准化规范:
    • 主机名标准化;
    • 日志存储标准化;
    • 日志格式标准化;
    • 域名使用标准化;
    • 软件安装目录结构标准化;
    原则:
    1. 主机名尽量能看出更多信息,比如服务、模块、机房等;
    2. 日志是排查问题的重要信息,一定要标准化,方便手工排查,更是为了以后用工具处理打下基础。
    11、资源管理规范
    • 服务器
    • vip
    • 域名
    • 证书
    • 代码
    原则:
    1. 资源之间是有关系的,要建立有关系的资源管理。
    这里只列了一些常见的业务规范,还有很多规范是要在业务实际问题中去制定的,规范代表了运维的最佳实践,在DevOps建设中非常重要。

    二、建工作制度

    制度对应着工作的做事流程方法,会影响到文化,制度的建设情况,也反映了解决问题的层次,好的制度是应该能够系统化、工具化、可执行、可量化的,这样在后期才好用DevOps实现,把制度友好的落到运维平台上。 制度的产生不应该是解决一个case,而是科学的解决一类问题,制度的执行如果仅靠人的自觉自律,是靠不住的,一定要尽可能落到技术上。
    • 上线审批制度
    • 合规部署制度
    • 日志清理制度
    • 容量管理制度
    • oncall管理制度
    • 服务巡检制度
    • 故障管理制度
    • 安全管理制度
    • ……
    工作中最不缺的是各种制度,如何建是有技巧的,也体现了一个运维的能力,这种能力坚持下去就会变为一种文化,例如考虑问题看到本质,解决问题解决根本。 另外,制度的建立要一定要本着长远的眼光,科学的态度,DevOps的思想(工具思维)。

    三、搭 DevOps 系统

    搭系统就是把前面的内容用技术的手段信息化,用科学的工具实现零散的资源管理、规范制度、手工操作,最理想的目标是“一站式运维”,工程师不需要切换系统,一个平台解决所有事情。 但要管的东西实在太多了,为了专业,市面上首先出现了解决单个点的优秀方案,比如说zabbix、Jenkins…..但从用户的角度看就像“五行有了缺一个串”,解决一个业务问题,需要打开N多个系统,来回跳转,这种方式令人崩溃。好一点的大厂做个单点登陆,解决了账号混乱的问题,不过依旧是一堆系统,用户体验差、操作效率低。 实际上,这些单点的解决方案非常重要,我们在思考设计DevOps的时候,想要做到高质量、低成本,必须用好这些方案像拼积木一样做资源整合,把他们当作底层的轮子,站在巨人的肩膀上做系统,力争在应用层做到“一站式”,工作细分到这个程度,指望一个系统解决所有底层问题是不现实的,用图示意如下。 3f12cb1396f91cbb352131085759a240.png 可以看到,整个工具体系分为了两层,一层是底层的轮子层,这一层面向的是单个主题的解决,讲究深度和系统的解决一类问题,上层是面向SRE的应用层,也可以说是业务层,业务层通过底层轮子封装后管理了资源、规范制度、运维服务(运维提供的服务)这三类内容,所有的轮子通过一套账号和权限体系打通。 我们要用好开源社区优秀的轮子,特别是小厂,没有必要重复建设,要通过轮子的api接口做好应用层的流程封装,通过应用层的集成,做到一站式操作,应用层作为和SRE的用户接口,体现了一个 DevOps 的用户体验,轮子可以复杂,“一站式运维平台”要做到尽可能简单、优雅。 写到这里,希望对从业的你有所启迪。 来源:公众号运维网咖社,点击查看原文。 GOPS 2020 · 深圳站刚刚结束,GOPS 2020 · 上海站要来啦,11月27-28日,相聚上海,专场图先献上~ 20836e94d3888dea1bdb35b6ccb941fb.png 近期好文:

    以小见大,彻底理解 cookie,session,token 之间的关系,通俗易懂

    全球互联网流量下降3.5%只因一次配置错误?百岁 IBM 宣布拆分!10 月的编程语言Python 有望第二!| 一周IT资讯

    谁是行业翘首?| 2020年IT技术领导力颁奖盛典与你同行!

    “高效运维”公众号诚邀广大技术人员投稿,

    投稿邮箱:jiachen@greatops.net,或添加联系人微信:greatops1118.

    6bea234a3b4c4c0447a8b29bb3e423ea.png点个“在看”,一年不宕机
    展开全文
  • 1.6 理想实践,开发运维一体化 在数据行业那么久,我们总希望能够通过自己的努力,将好的想法落地,渐渐地改变行业中的不合理之处,让这个技术世界变得美丽一点点。 那么这个行业里有什么迫...

    本节书摘来自异步社区出版社《Oracle性能优化与诊断案例精选》一书中的第1章,第1.6节,作者:盖国强 , 李轶楠 ,更多章节内容可以访问云栖社区“异步社区”公众号查看。

    1.6 理想实践,开发运维一体化

    在数据行业那么久,我们总希望能够通过自己的努力,将好的想法落地,渐渐地改变行业中的不合理之处,让这个技术世界变得美丽一点点。

    那么这个行业里有什么迫切需要改变的?

    作为资深的DBA你可能会发现,我们10年前处理的问题和今天没有什么不同。针对数据库的运维巡检日复一日,SQL优化应对全表扫描或是隐式转换,转眼就耗费了经年的时光。所以我们有一个理想,不要让DBA重复在这些无休止的工作上,或者至少能够做得更有价值,也力争能够改变用户在使用数据库的过程中,屡见不鲜的事后救火。

    所以我们第一个在国内提出了“SQL审核”“智能巡检”等理念,希望真正能够通过自动化运维、工具化约束,去改善SQL开发质量、发现和凸显问题,从而防患于未然,提升系统稳定性,改善数据库运维的现状。我们相信通过规范化、标准化、智能化,才能够不断推动业界向前。

    早在2011年,我们基于对于业界的思考,就开始开发了一款SQL审核产品,称为z3,如图1-10所示。它可以审核开发测试阶段的SQL,发现问题,提出建议,希望由此将运维DBA和开发结合起来。我们从未想过,这居然就是今天最热门的DevOps所讨论的范畴。

    image

    通过不断地呼吁和倡导,今天我们非常欣喜地看到国内很多企业都开始去开发这方面的工具,去推行SQL审核的理念。

    那么什么是DevOps呢?维基百科的定义如下所示。

    DevOps(Development和Operations的组合词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

    从这个定义可以看出DevOps实际上是一种文化上的改变。开发和运维通过更多的沟通达成更可靠的系统输出,从而为企业的共同目标而加注动力。在2015年Gartner的技术成熟度曲线上,DevOps正处于巅峰。

    而根据多年的行业经验,我们认为DevOps在Oracle数据库的最佳实践应该就是SQL审核。江苏移动技术专家戴建东的一段感触之言为我们提供了来自实践的依据,他明确提到:

    “其实在生产中,绝大多数Oracle的业务系统出现问题都是SQL导致的。但是大多DBA,尤其是偏运维的DBA对SQL并不擅长,这些DBA承担着数据库运维和维护稳定性的职责,而他们对这些问题可能又无能为力。原本SQL的质量应该是开发层负责的问题,但目前的现状是,开发人员管不了,运维人员不擅长。所以当系统出现问题的时候,就需要专业人员“救火”,而事发或事后救火往往是业务已经遭受了损失。”

    SQL审核的理念就是,将这些“开发人员管不了,运维人员不擅长”的核心SQL问题抽取出来,作为DevOps的范畴。通过来自运维的经验,指导和辅助开发完成高性能的SQL改写,并且不断通过自动的SQL审核工具和专家的修改建议相结合,推进开发质量的提升,改善系统的稳定性,将性能事故消弭于无形。这也正是DevOps的理想所在。

    对于开发团队来说,持续的进行SQL培训我认为非常重要,开发的SQL能力提升了,对于DBA只有好处,数据库的稳定性自然会得到提升。DBA也有职责去和开发沟通,对他们进行面向运维高性能培训。在Oracle DevOps时代,DBA要勇于承担责任,去推进变化。而且在DBA的学习过程中,就是要不断深入去了解各个层面的知识,才能不断进步、融会贯通,找到如鱼得水、游刃有余的感觉。也才能从工作中找到自信和乐趣,进而培养和巩固兴趣,在完善自我的同时帮助他人,提升团队。

    在今天的云时代,各个领域都在发生变化,DBA的领域同样面临挑战,表达一下我的观点。

    (1)DBA从后端走向前端才能更充分的体现其技术价值。

    (2)应用向着预防问题方向演进永远比事后救火更重要。

    所以慢慢很多企业开始在开发环节,以开发DBA来进行把关,以SQL审核优化来控制质量。我建议DBA们关注一下这个方向和变化。在现实中,解决单个问题往往是简单的,但是我们应该思考如何去防范一类问题,让更多的人免于重复落入类似的故障。

    从经验到规范,从规范到规则,这是DBA工作更高价值的体现。当我们能够将经验固化成SQL、算法或者程序之后,才能帮助到更多的人。我想,只要我们每个人在自己熟悉的领域都能够努力一点点,就能够一起将我们所从事的行业变得美好一点点,从而也会使得我们的世界变得美好一点点。

    云和恩墨在云的时代,正在致力于以团队智慧和经验,衍生产品,以产品服务更多的客户和DBA们,进而推进行业的进步

    展开全文
  • 本文根据陈能技老师在〖2016 Gdevops全球敏捷运维峰会广州站〗现场演讲内容整理而成。 (点击底部“阅读原文”获取陈能技演讲完整PPT) 讲师介绍 陈能技,DBAplus社群原创专家,新炬网络首席DevOps专家。14年开发...
  • 但是我们的业务场景天然是一个技术体系的管控,所以我们认为devops不应该还停留在单个系统开发运维一体化的方法论认知上,所以希望我们的devops的定义是单个系统ops之上的“ops”,所以本质上我们和集团其他所谓的...
  • 《阿里巴巴DevOps实践指南》: https://developer.aliyun.com/article/785093?spm=a2c6h.13528211.0.0.228c4307jitPjS 运维升级: https://www.sohu.com/a/437368225_612370?sec=wd
  • 它沉淀了阿里巴巴创立18年来在研发、运维方面积累的经验和产品。特别适用于希望通过互联网方式改革企业研发过程,实现持续集成,持续交付和DevOps的企业。 据了解,研发协同云包含三款产品。一站式智能研发协同平...
  • 它沉淀了阿里巴巴创立18年来在研发、运维方面积累的经验和产品。特别适用于希望通过互联网方式改革企业研发过程,实现持续集成,持续交付和DevOps的企业。研发协同云包含三款产品: 一站式智能...
  •   Cockpit平台演示 ...#进入管理界面 可以参考 CPU MEM STOREGE等等信息,可以自动管理Docker容器,启动Container #展示某个Container的配置信息,内网IP/Gateway,内网端口,宿主机...
  • 经过前三部分的内容(视频),我相信大家对如何使用云计算平台和WordPress来创建一个博客站点已经有了较为完整的认识。...这样的系统在ALM(应用生命周期管理)中叫做开发运维一体化(DevOps)系统。
  • 从容器技术发展背景和趋势出发,重点分享云效&Docker容器如何联合助力开发运维一体化和企业应用现代化,让DevOps落地。同时推出Docker EE & 飞天敏捷版产品,分析对比它们相对开源产品的价值。 日程安排 ...
  • 自动化运维一体化

    千次阅读 2018-11-11 21:53:43
    运维一体化中的平台一体化,指的是运维一体化与平台一体化,其中运维一体化是数据中心在运维方面的运营体系,它包括三方面:人员组织一体化、流程一体化、平台一体化。 一、转型: 和目前大部从运维团队一样,我们...
  • 运维一体化中的平台一体化,指的是运维一体化与平台一体化,其中运维一体化是数据中心在运维方面的运营体系,它包括三方面:人员组织一体化、流程一体化、平台一体化。 一、转型: 和目前大部从运维团队一样,我们...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 16,007
精华内容 6,402
关键字:

开发运维一体化