Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (17)
Ähnlich wie 云运维的理念和思维
Ähnlich wie 云运维的理念和思维 (20)
云运维的理念和思维
- 2. • 姚 昕 • 18896724880 • 恩墨学院Oracle高级讲师 • Cloudera认证讲师 • Oracle 10g、11g、12c OCM认证 • 曾在IBM任职亚太客户支持 • 中国移动（苏州）研发中心运营支撑部 • http://blog.csdn.net/kiwi_kid • yaoxin@cmss.chinamobile.com
- 5. 运维提升的阶段
- 10. DevOps 的各种工具 ⦁代码管理（SCM）：GitHub、GitLab、BitBucket、SubVersion ⦁构建工具：Ant、Gradle、maven ⦁自动部署：Capistrano、CodeDeploy ⦁持续集成（CI）：Bamboo、Hudson、Jenkins ⦁配置管理：Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail ⦁容器：Docker、LXC、第三方厂商如AWS ⦁编排：Kubernetes、Core、Apache Mesos、DC/OS ⦁服务注册与发现：Zookeeper、etcd、Consul ⦁日志管理：ELK、Logentries ⦁系统监控：Datadog、Graphite、Icinga、Nagios ⦁性能监控：AppDynamics、New Relic、Splunk ⦁压力测试：JMeter、Blaze Meter、loader.io ⦁HTTP加速器：Varnish 消息总线：ActiveMQ、SQS ⦁应用服务器：Tomcat、JBoss、IIS ⦁Web服务器：Apache、Nginx ⦁数据库：MySQL、PostgreSQL等关系型数据库；cassandra、 mongoDB、等NoSQL数据库 ⦁项目管理（PM）：Jira、Asana、Taiga、Basecamp、Pivotal Tracker
- 13. 实践1：持续集成过程 持续编译 持续代码 检查 持续测试 持续部署 持续报告 持 续 集 成 体 系 建 设 1 制定基本构建流程 2 加强代码自动验证环节 3 加强单元测试环节 4 加强自动化测试环节 5 加强自动部署环节
- 15. 实践1：基于容器技术的快速部署 容器并不包含一个单独的操作系统，而是基于已有的基础设施中操作 系统提供的功能来运行的。 将应用程序及所有程序的依赖环境打包到一个容器中，容器可以运行 在任何一种 Linux 服务器上。这大大地提高了程序运行的灵活性和可 移植性。 虚拟机是操作系统级别的资源隔离，容器本质上是进程级的资源隔离 Virtual Machine Docker
- 16. 实践1：Docker的持续部署
- 17. 服务器 操作系统 应用 IT基础架构发展阶段1：裸机时代 • 基础架构利用率低 • 每台服务器上运行一个应用程序： • 典型的x86 服务器部署平均达到的 利用率仅为总容量的10% 到15% • 物理基础架构成本日益升高 • 大多数计算基础架构都必须时刻保 持运行，因此耗电量、制冷和设施 成本不随利用率水平而变化。 • 管理成本不断攀升 • 服务器数量太多难以管理，新服务 器和应用的部署时间长，硬件维护 需要数天/周的变更管理准备和数 小时的维护窗口。 • 故障切换和灾备困难： • 兼容性差。系统和应用迁移到新的 硬件需要和旧系统兼容的硬件系统。
- 18. 服务器 操作系 统 应用 操作系统 虚拟机 操作系 统 应用 虚拟机 操作系 统 应用 虚拟机 云平台 服务器 操作系统 IT基础架构发展阶段2：虚拟化时代 以虚拟化技术为基础，以虚拟机为单位， 将资源提供给用户。 • 提高资源利用率 • 将一台高性能的服务器虚拟 成多个虚拟机，在物理上虚 拟机共享宿主服务器的硬件 资源，而逻辑上各自独立， 可在各虚拟出的服务器上运 行不同的应用，各司其职， 互不干扰。 • 降低管理、运维成本 • 简化服务器的部署、管理和 维护工作，降低管理费用 • 核心技术 • 计 算 虚 拟 化 、 SDN 、 OpenStack管理
- 19. 服务器 应用 操作系统 应用 应用 服务器 操作系统 资源统一管理、调度 IT基础架构发展阶段3：以应用为中心时代 • 问题 • 虚拟机构成的集群仍然难 以运维，对于每个虚拟机 的维护也并非容易，用户 遇到的问题和直接维护物 理机集群基本相似 • 用户需求 • 应用能够获取资源，快速 启动，服务可以无限扩展 （不在乎怎样运行及运行 在哪），服务失败时能被 自动检测并修复，应用易 于迁移。 Datacenter Operating System（DCOS） 目标：整合数据中心资源虚拟池化，开放诸如CPU、内存和I/O 这些基本资源而不是虚拟机。就像操作系统将PC的处理器和 RAM放入资源池，使其可以为不同的进程协调分配和释放资源 核心技术：容器集群资源管理、容器
- 20. DCOS分布式“系统”
- 22. Mesos的结构（2） ① Mesos master从slave节点获 取资源offer，调用分配模块决 定将资源分给哪个框架。 ② 框架调度器从Master接受资源 offer。 ③ 当接受到资源offer后，框架调 度器会检查offer是否合适。如 果合适，接受该offer并向 master返回在slave上运行的 的执行器列表。 ④ Slave节点分配所请求资源并运 行任务执行器，任务执行器在 slave节点上运行框架下的任务。
- 23. 基于Mesos的资源分配
- 26. OpenStack安装非常困难, 困难主要来自于: 开源项目，系统本身开发时间短，不够稳定, bug多。 配置自由，灵活度高，很难将所有的配置项都试全。 Fuel是Mirantis公司开发的一个开源的OpenStack 套件，具有以下优点: 安装简便: 全部通过图形界面操作。 配置灵活: 支持Redhat和CentOS, 支持Ceph开源存储软 件。 稳定可靠: 已经在多家公司商用。 Mirantis fuel从http://software.mirantis.com 下载, 可以下载iso文件 云计算自动化部署工具-Fuel
- 27. Fuel 并不是一个大的整体，它由几个独立的组件组成。 UI 一个用JaveScript写的 页面 应用，主要还是用 bootstrap框架 Nailgun 提供REST API 以 及部署数据管理。 Astute Nailgun任务的执 行者。 Cobbler 提供快速网络安 装系统 Mcollective 一个构建服务 器编排和并行工作执行系 统的框架 OSTF Openstack testing framework,提供健康检查 云计算自动化部署工具-Fuel
- 28. 云计算自动化部署工具-Fuel
- 29. 云计算自动化部署工具-Fuel
- 30. 云计算自动化部署工具-Fuel
- 31. 云计算自动化部署工具-Fuel
- 32. 云计算自动化部署工具-Fuel
- 33. 云计算自动化部署工具-Fuel
- 35. 实践2：实现用户操作的可视化
- 36. 实践2：苏研-OP系统
- 38. 工具一：Ansible 基于Python研发 。 实现了批量操作系统配置、批量程序的部署、 批量运行命令等功能。 仅需在管理工作站上安装 ansible 程序配置 被管控主机的 IP 信息，被管控的主机无客户端。 (1)、连接插件connection plugins： 负责和被监控端实现通信； (2)、host inventory：指定操作的主 机，是一个配置文件里面定义监控的主 机； (3)、各种模块核心模块、command模 块、自定义模块； 实践2：实现运维的自动化与可视化
- 41. 实践3：构建立体化的监控体系 停机费用成本 = 部署频率 * 版本迭代失败概率 * 平均修复 时间 * 断电的金钱损失
- 47. 云时代日志的特点 系统规模大 业务模块多 日志量大 日志数据之间相 互关联 SLA要求比较高 如何在灾难性事件发生时， 能够做好相应的准备 如何在第一时间捕获到错 误动态 如何针对不同的业务逻辑 建立保障措施 如何利用关联性挖掘有价 值的信息 IT系统信息 • 服务器 • 网络设备 • 存储设备 • 操作系统 • 应用软件 用户行为 • 用户行为 业务信息
- 48. 从 IT Operation Management (ITOM) 到 IT Operation Analytics (ITOA) 大数据技术应用于IT运维，通过数据分析提升 IT运维效率 • 可用性监控 • 应用性能监控 • 故障根源分析 • 安全审计 Gartner估计，到2017年15%的大企业会积极使 用ITOA； 而在2014年这一数字只有5% 实践4：IT运维分析
- 49. 日志管理系统的进化 日志1.0 数据库 日志2.0 Hadoop 日志3.0 实时搜索引擎 日志没有集中处理 使用脚本或者命令查看 日志只做事后追查 没有实时监控、分析 使用数据库存储日志 无法适应TB级海量日志 数据库的schema无法适 应各种各样的日志格式 无法提供全文检索 Hadoop 批处理，不够及时 查询慢 数据离线挖掘，无 法做在线分析 Storm/Spark 对日志实时检索、分析 日志实时搜索分析引擎 快 日志从产生到搜索分析出结 果只有几秒延时 大 每天处理TB级别的日志量 灵活 可搜索、分析任何日志
- 51. 云环境日志管理的实践—数据流程图 数据库 文本文件 数据流 采集客户端 采集客户端 采集客户端 中间数据存储 实时分析 离线分析 数据挖掘 监控报警 分布式索引 结果可视化 实践4：日志管理软件Log-Manager
- 57. 运维团队的能力要求：
- 58. 运维的个人能力要求：
- 59. 谢 谢
Hinweis der Redaktion
- 如今，我们的工作和生活都离不开数字化，无论是内联网、互联网还是物联网，都通过云计算、大数据、智能终端为我们提供各种服务。在数字化社会中，我们既提供内容，又消费内容，信息以前所未有的速度传播，应用不断地渗透到每个角落，每个人都无法离开。 运维管理-作为数字化背后的支撑力量，随着“互联网+”战略的深入，运维正在进入到下一个时代，将面临更加宽泛的领域、更加灵活的场景， 如果我们尽可能的去解决掉当前面临的这些问题，是不是我们的运维工作也就轻松好多了。 试想一下这样一个美好的场景，所有的设备都是在云端了， 我们根本不需要维护任何的硬件，所有的部署工作都是自动化的，一个按钮，一个命令就能够完成所有的部署工作 系统能够轻松的应对双11这样大业务量的 遇到故障以后，能够及时快速定位故障。 如果能够构建这样的一个体系，那么运维工作就不再是一个繁重的负担了，变成一个轻松惬意的工作。 当然，有利有弊，有这样的系统，很多运维人员估计也要失业了
- 那么问题来了，如何的去构建这样的理想中运维的系统呢？ 所谓一口吃不下不下一个胖子，万丈高楼平地起，就像国民岳父王健林所说的，先定一个小目标，然后再去逐步实现大目标。 第一阶段：精益化的基本思想可以用一句话来概括，即：Just In Time（JIT），及时性，翻译为中文是“旨在需要的时候，按需要的量，完成工作”。精益化的是一种被动的处理问题的方式，更好能快的完成工作。 第二阶段：标准化，十个指头有长短，人的能力也是有大有小，能力不同，眼界不同，每个人处理工作的过程都是不一样的，有些人能够按照精益化的方式处理问题，但是某些人能力不够，可能就没法做到了。但是，如果我们把所有的事情都形成一个标准，并形成文档，然后遇到故障或者问题，就按照这样的标准去执行，是不是就能够保证所有的工作的工作都能够按照一种精益化的方式来完成了。 第三阶段：自动化，人有的时候其实是很懒惰的，对于很多的运维工作，你在定义好标准以后，就是是重复而乏味的工作了，比如给服务器打个补丁，生产系统有上千台机器，如果我们一台台的登录上去进行操作，估计很多人都会被这样的工作给逼疯。这个时候，就很需要自动化运维了，越是大的系统，对自动话运维的渴望就越强烈。通过自动化运维，能够节约大量的时间以及人力，物力。 第四阶段：可视化，在解决了温饱问题以后，是不是就要去追求一些物质的享受了。运维工作也是一样。运维工作虽说是后台工作，领导过来参观，我们就要在尽可能的情况下，也要展现我们的工作量，可视化的报表展现在此刻就变的必要了，得到领导的肯定，升职加薪，赢取白富美，走上人生巅峰就不再是梦想。此外，通过可视化的操作，我们还能够把很多的运维操作封装起来，降低我们的运维成本 最后一个阶段，也是运维的最高境界，就是智能化，运维这份工作，大部分情况下，是一个被动的过程，接受故障然后再处理故障，但是到了智能化阶段，运维所处的角色就变了，运维作为一名审核者。就拿Oracle数据库来举例， 索引 绑定变量 在智能化阶段，运维工作者通过各种各样的系统或者工具，要能够具备提前发现问题并解决问题的能力，变被动为主动，防患于未然。
- DevOps一次词的来自于Development和Operations的组合，DevOps概念早先升温于2009年的欧洲，因传统模式的运维之痛而生 一方面是敏捷开发者发现，虽然产品被很快设计出来，但部署却比较花费时间，手动部署和配置也会引入很多人为错误。此时，敏捷开发团队希望可以自动完成所有重复性的任务，当然也包括部署在内。 另一方面来自于一些互联网公司，这些公司业务增长飞快，有时会在两个星期内就要增加上千台服务器，单纯人工的方式完成，耗费了大量人力，运维成本太高，这时他们想到了敏捷设计，希望将敏捷设计应用到运维当中，实现敏捷运维。 敏捷运维与传统的人工运维管理完全不同，敏捷运维完全自律，按照设定好的程序去执行，确保所有一切内容都在控制之内，敏捷运维引入了自动化的东西，抛弃了手动操作。 DevOps的核心，就是Dev用D的能力延伸到Ops，而Ops则把O的能力传递到Dev，两者相结合结合突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
- 通过敏捷运维，我们可以 下面的几点 Puppet公布的2016年DevOps调查报告中，根据全球4600位各IT公司的技术工作者的提交数据统计，得出高效公司可以完成平均每年1460次部署。与低效组织相比，高效组织的部署频繁200倍，产品投入使用速度快2555倍，服务恢复速度快24倍。在工作内容的时间分配上，低效者要多花22%的时间用在为规划好或者重复工作上，而高效者却可以多花29%的时间用在新的工作上。所以这里的高效不仅仅指公司产出的效率提高，还指员工的工作质量得到提升。
- 什么样的运维，才够算是敏捷运维？对于传统运维来说，仅仅包含发布，部署，运营，监控的这些黄色的部分，在敏捷运维中，将规划，代码，构建，测试的开发环节跟后期的部署环节进行了连接，形成了如图所见的这样一个能力环。 它希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。
- 这张ppt列出了敏捷运维的各种工具，大家可以按照各自的运维需求灵活的选用一些工具，来提高我们敏捷运维的能力！ 但是，我们需要知道的是，很多人存在这样的误区，以为只要使用这些工具就是敏捷运维了，实际不是这样的。就像我们拥有了电脑，会使用电脑，但不一定会用电脑完成各种编程，输出很多的功能软件。电脑只是一个工具，我们需要通过给电脑一些指令，才能按照我们的意图完成。 在敏捷运维中，软件工具就是这样的角色，必须要我们给予它各种处理业务的能力，它才能自动完成，只要我们设计好了未来数据中心故障、扩容、业务变更遇到的场景，赋予工具自动操作的权利，那么工具就会按照我们设计的程序去自动执行。为工具制定各种各样的自动执行脚本，是敏捷运维的关键，这些脚本关系到敏捷运维的可用性。尤其是在突发事件的处理上，大规模业务扩容上的表现。
- 前面我们介绍了很多敏捷运维相关概念，那么如何把这些概念深入到实践呢？其实对于敏捷运维来说，总结到最后，其实就是四个过程 1， 2， 3， 4 下面我们逐一的来看看
- 首先我们来看下，DEVOPS能力环中的第一个部分，持续集成 持续集成，它其实是持续编译，持续代码检查，持续测试，持续部署，持续报告的总和。 持续集成通过自动化构建、自动化测试以及自动化部署加上较高的集成频率保证了开发系统中的问题能迅速被发现和修复，降低了集成失败的风险，使得系统在开发中始终保持在一个稳定健康的集成状态
- 这张图包含了从开发到部署的全部环节，先进行持续集成，代码开发完成以后进行自动化部署。 对于构建持续集成的环境，我们需要注意四个要素； 1， 2， 3， 4 Jenins是现在非常流行的持续集成CI服务器 GIT是版本控制软件当然了，我们也可以使用svn Jenins会在后台运行，轮询版本控制的存储库，一旦发现版本库出现变更，就会通过预定义的构建脚本进行项目的构建，Jenkins会根据项目需求将构建的任务分配到Slave端。一般的项目构建过程主要分为自动化编译和自动化测试两个阶段，这同样是你脚本发挥作用的阶段。 这儿就体现出了devops中的dev的重要性。
- 既然没有办法去构建这样一直持续部署的平台，那么我们就退而求其次，至少能够构建一套快速部署的系统。 做过系统集成的同学，可能或多或少的都有过这样的经历，很多系统，在家里面的测试环境部署，验证，一点问题都没有，但是到了客户现场进行部署的时候，就不说自动化部署了，很多时候手工进行数据的时候，都是各种问题频发，问题其实只有一个，就是客户现场的环境跟我们的开发测试环境是存在区别的，就因为这样的差异性，导致了我们的部署工作存在了很多的不确定性，从而阻碍了自动化部署的实现。 为了实现统一平台的部署，docker，这种容器技术在近两年发展势头凶猛。 容器并不包含一个单独的操作系统，而是基于已有的基础设施中操作系统提供的功能来运行的。 将应用程序及所有程序的依赖环境打包到一个容器中，容器可以运行在任何一种 Linux 服务器上。这大大地提高了程序运行的灵活性和可移植性。 这样张图上，很清晰的体现了虚拟机跟docker的区别， 虚拟机是操作系统级别的资源隔离，容器本质上是进程级的资源隔离 虚拟机多一层guest os的消耗
- Docker技术的出现，极大的改善了部署工作对于环境的依赖，从本质上提升了快速部署的效率。 如果作为生产环境中部署docker来说有几个明显的软肋： 1，缺乏故障监控，资源调度，故障自动转移的平台。 2，没有一个相对友好的用户界面和相对完整的API。 3，网络管理不完善。 为此，mesosphere公司在原有的docker技术上，结合了mesos推出了一套全新的dcos系统。
- 基础架构利用率低 每台服务器上运行一个应用程序：避免一个应用程序中的漏洞影响同一服务器上其他应用程序 典型的x86 服务器部署平均达到的利用率仅为总容量的10% 到15% 物理基础架构成本日益升高 为支持不断增长的物理基础架构而需要的运营、维护成本稳步攀升。大多数计算基础架构都必须时刻保持运行，因此耗电量、制冷和设施成本不随利用率水平而变化。 管理成本不断攀升 服务器数量太多难以管理，新服务器和应用的部署时间长，硬件维护需要数天/周的变更管理准备和数小时的维护窗口。 故障切换和灾备困难： 兼容性差。系统和应用迁移到新的硬件需要和旧系统兼容的硬件系统。
- 著名的点评网站yelp使用mesosphere DCOS实现了灵活的连续化部署，大大提高了其数据中心的性能；yelp测试团队每天已经启动100万个docker容器，运行着大约1700万独立测试, 一些计划直接在机器上,一些在容器里--全通过Mesos管理。 Mesos：Twiiter/eBay公司主导的多应用框架下的容器资源调度，于2009年立项； 说得更确切一点，当我们逐步接纳了以容器为单位部署和运行应用之后，运维人员终于可以从无休止的包管理，莫名其妙的环境差异，繁杂重复的批处理和任务作业的中稍微回过一点神来，开始重新审视自己手中的物理资源的组织和调度方式：即我们能不能将容器看作传统操作系统的进程，把所有的服务器集群抽象成为统一的CPU、内存、磁盘和网络资源，然后按需分配给任务使用呢？ 生态：2011年开始在生产环境（Twitter/eBay/AirBNB/Apple Siri）使用，生态系统成熟 Mesos支持16+应用框架集成，如Marathon, Spark/Storm等 Eaton选择测试Mesosphere的打包版本*，包含了诸如Marathon的工具
- 在虚拟化时代，我们解决了硬件资源限制浪费的问题，但是虚拟机构成的集群仍然难以运维，对于每个虚拟机的维护也并非容易，用户遇到的问题和直接维护物理机集群基本相似，而且用户的需求应用能够获取资源，快速启动，服务可以无限扩展（不在乎怎样运行及运行在哪），服务失败时能被自动检测并修复，应用易于迁移也并没有得到很好的解决。 当我们逐步接纳了以容器为单位部署和运行应用之后，运维人员终于可以从无休止的包管理，莫名其妙的环境差异，繁杂重复的批处理和任务作业的中稍微回过一点神来，开始重新审视自己手中的物理资源的组织和调度方式：即我们能不能将容器看作传统操作系统的进程，把所有的服务器集群抽象成为统一的CPU、内存、磁盘和网络资源，然后按需分配给任务使用呢？
- 这就是一种分布式系统的架构 和单机Linux操作系统相比，虽然分布式系统还没有成熟到成为“分布式操作系统”，但它和单机Linux一样要解决五大类操作系统必需的功能，即资源分配、进程管理、任务调度、进程间通信（IPC）和文件系统，可分别由Mesos、Docker、Marathon/Chronos、RabbitMQ和HDFS/Ceph来解决，对应于Linux下的Linux Kernel、Linux Kernel、init.d/cron、Pipe/Socket和ext4 Mesos不要求计算节点是物理服务器还是虚拟服务器，只要是Linux操作系统就可以。Mesos可以理解成一个分布式的Kernel，只分配集群计算资源，不负责任务调度。基于Mesos之上可以运行不同的分布式计算平台，如Spark、Storm、Hadoop、Marathon和Chronos等。Spark、Storm和Hadoop这样的计算平台有任务调度功能，可以直接使用Mesos SDK跟Mesos请求资源，然后自行调度计算任务，并对硬件容错。Marathon针对服务型分布式应用提供任务调度，比如企业网站等这类需要长时间运行的服务。通常网站应用程序没有任务调度和容错能力，因为网站程序不太会处理某个后台实例挂掉以后要在哪台机器上重新恢复等这类复杂问题。这类没有任务调度能力的服务型分布式应用，可以由Marathon来负责调度。比如，Marathon调度执行了网站服务的一百个后台实例，如果某个实例挂掉了，Marathon会在其他服务器上把这个实例恢复起来。Chronos是针对分布式批处理应用提供任务调度，比如定期处理日志或者定期调Hadoop等离线任务。
- Mesos框架是一个在Mesos上运行分布式应用的应用程序，它有两个组件： 调度器 : 与Mesos交互，订阅资源，然后在mesos从服务器中加载任务。 执行器 : 从框架的环境变量 配置中获得信息，在mesos从服务器中运行任务。
- Mesos最大的好处是能够对分布式集群做细粒度资源分配。左边是粗粒的资源分配，右边是细粒的资源分配。 细粒度这种分配方式的最大好处就是 1，提高了硬件资源的整体的使用率 2，提高了更多的容错性能。 图左边有三个集群，每个集群三台服务器，分别装三种分布式计算平台，比如上面装三台Hadoop，中间三台是Spark，下面三台是Storm，三个不同的框架分别进行管理。右边是Mesos集群统一管理9台服务器，所有来自Spark、Hadoop或Storm的任务都在9台服务器上混合运行。Mesos首先提高了资源冗余率。粗粒资源管理肯定带来一定的浪费，细粒的资源提高资源管理能力。Hadoop机器很清闲，Spark没有安装，但Mesos可以只要任何一个调度马上响应。最后一个还有数据稳定性，因为所有9台都被Mesos统一管理，假如说装的Hadoop，Mesos会集群调度。这个计算资源都不共享，存储之间也不好共享。如果这上面跑了Spark做网络数据迁移，显然很影响速度。然后资源分配的方法就是resource offers，是在窗口的可调度的资源自己去选，Mesos是Spark或者是Hadoop等等。
- 它是一个mesos框架，能够支持运行长服务，比如web应用等。是集群的分布式Init.d，能够原样运行任何Linux二进制发布版本，如Tomcat Play等等，可以集群的多进程管理。也是一种私有的Pass，实现服务的发现，为部署提供提供REST API服务，有授权和SSL、配置约束，通过HAProxy实现服务发现和负载平衡。
- 前面介绍的是在持续集成和持续部署的一些通过的实践经验。 对于云计算，大数据的产品，苏研结合一些开源技术，开发了一些专门用于云计算，大数据的自动化部署软件，在这儿我就简单的做个介绍。
- 用户管理的学习成本问题，在座的各位，大家对openstack了解多少，那么有多少人，能够不借助dashboard，手工通过命令的方式去创建虚拟机的？ 这张图就是整个openstack创建虚拟机的过程。 对于一个初学者而言，从keystone，到nova，再到glance，neutron，cinder，各个组件之间相互交互的28个流程能够理清，就需要花很多的时间了。 很显然，过高的学习成本阻碍了用户的体验
- 用户管理的学习成本问题
- 在部署完成以后，就要开始展开日常的运维工作了，那么如何能够提升运维效率呢？ 很显然的，你再所有的工作都是手工完成的情况下，这样的运维工作必然是没有效率的，现在生产上，随随便便的就是上千台服务器，如果你单单的只是手工登录这些服务器，可能就需要好几个小时，每天8小时工作时间，一大半的时间都用来登录服务器了，。 想要运维工作做得好，自动化运维不可少。 运用自动化运维作业工具，将日常重复性的运维作业内容固化，实现自动化备份、自动化分析报表等功能，提高运维效率，使运维人员有时间开展系统优化提升工作。
- (1)、轻量级，无需在客户端安装agent，更新时，只需在操作机上进行一次更新即可； (2)、批量任务执行可以写成脚本，而且不用分发到远程就可以执行； (3)、使用python编写，维护更简单，ruby语法过于复杂； (4)、支持sudo。
- 用户管理的学习成本问题
- 我们讲完了集成自动化部署，以及自动化的运维实现，系统就进入了日常运营阶段了。 在日常运维阶段，我们需要做的最重要的事情就是处理各种故障，如何去快速的发现故障，并且排查故障， 我们需要构建一个立体化的监控体系， 对于用户而言，他们直观感受到的是程序的访问和响应时间， 所以，对业务的巡检监控中，应包含响应时间指标，业务访问量指标，活跃用户数指标以及访问错误率指标。 剩下来的，就是包含基础设置 以及各种软件服务相关的监控 在ppt上列出了一些指标，但这些指标并不是绝对的，我们需要根据不同的系统以及监控的需求，定义符合业务需求的各种指标，来最大化的满足我们的日常运维需求
- Cloud master是苏研自主研发的云计算的监控工具，通过cloud master既可以统计整体的资源情况，也能够根据状况，
- 对于大数据产品的监控，苏研依旧统一集成到了hcontrol工具中使用开源的metrics组建来进行监控， Metrics提供各种图表形式的实时监控，并且可以支持自定义
- 对于故障报警，Hcontrol也能够进行hen
- 讲完了监控，我们再来看下对于日志处理的实践经验. 所有的软件，只要它运行，就会产品相关的日志，对我们运维来说，接触的日志主要包括； 这些日志，有着xxxx的特点 系统规模大 单个资源池服务器规模100+以上 业务模块多 单个控制节点服务进程超过20个 日志量大 100台服务器规模资源池，每天日志量达到3000w条 日志数据之间相互关联 SLA要求比较高 云平台承载的业务越来越多，对平台稳定性要求越来高
- 前面我们说过，运维工作，最高的境界是智能化运维，如何做到智能化运维，我们需要从IT Operation Management 升华到ITOA阶段 所谓的ITOA就是 大数据技术应用于IT运维，通过数据分析提升IT运维效率 • 可用性监控 • 应用性能监控 • 故障根源分析 • 安全审计
- 当今业界主流的日志管理系统，已经经历了三次的演进。
- 我们苏研的Log-Manager产品就是基础日志3.0这样的目前而设计的系统，
- 通过flume进行日志采集，到hdfs上进行存储，
- 苏研自有IDC已投入使用，稳定运行近一年时间。研发测试区100台物理机运行着BC-EC，支撑着研发部近2000台研发用虚拟机的运作，三台控制节点上每天会产出500G左右的日志数据。