XP+devOps开发模式与scrum敏捷开发对比,docker虚拟化
我们现在用的就是典型的XP+devOps模式，已经放弃scrum了
现在还很多公司弄docker虚拟化
docker非常复杂，当然如果只是用别人的只用记一个docker命令就行了
docker虚拟化消耗额外的系统资源较少 传统虚拟化会占用一点系统资源。通常日志是写在挂载进去的盘 或者直接通过其它协议扔给日志中心服务器
传统虚拟化 启动 销毁 部署 时间都较长
docker部署这些就很短 把一个应用(nginx php node) 等等当成一个服务来用
devOps模式 听朋友说他公司里面执行起来不容易
要各部门配合得很好才行
主要是人的问题， devOps对核心程序员要求极高，一般都得是全栈程序员，而且基本上研发团队都必须是
一个能够做devOps的团队，核心程序员必须是后台运维高手，能够自己编写虚拟机脚本，熟悉vagrant，docker ，snappy这些，会写自动化脚本
一般的公司做不了的，你哪里能招到这么多全栈的
只能是全部招有多年经验的了
其实一般三个牛人，并且性格足够互补，超过几十倍的由一般人员组成的团队
而且这几个最好是合伙人或者联合创始人
不过也是很难找到刚好互补又能够一起出来创业的
===========================================
http://blog.oneapm.com/apm-tech/687.html
DevOps 发展融合运维可视化
DevOps，是开发（Development）和运维（Operations）的组合，代表一种文化、运动或实践，旨在促进软件交付和基础设施变更软件开发人员（Dev）和 IT 运维技术人员（Ops）之间的合作和沟通。它的目的是构建一种文化和环境使构建，测试，发布软件更加快捷，频繁和可靠。
现在2016年 DevOps 逐渐成为主流，来自云端、移动和社会等基本需求的驱动将促使越来越多的公司认识到采用 DevOps 最佳实践可能获得的文化、性能和经济效益。
精简灵活的公司已经在过去几年感受到了 DevOps 和持续交付带来的好处，而成熟的大企业也意识到了它们的价值，开始进行文化转型。但是这些企业对待 DevOps 的态度相当谨慎。所以预计在2016年，在广泛使用 DevOps 之前，企业会在非关键的新 IT 项目中进行 DevOps 测试实践，这将涉及进程、自动化、协作和工具等方面，其间的协同合作也极大的提升了工作效率。
通过查看 IT Central Station 中关于 DevOps 解决方案的真实用户评论，可以发现研究和购买 DevOps 解决方案的用户已经发生了变化。之前，许多评论都是 DevOps 经理和发布经理写的。现在则会看到很多 IT 行业的其他职能单位---架构师、客户服务经理、中间软件专家、网络工程师及其他人写的关于 DevOps 工具的评论数量正在增长。DevOps 工具正被越来越多的主流 IT 买家列入2016年的预算当中。
现在，较为成熟的 DevOps 购买方都来自软件和技术世界，这类买家往往很早就采用了现代实践和技术。不过另一面，较大型的企业和财富500强公司的 DevOps 采用率也在在逐步攀升。预计2016年，DevOps 将成为一项优势策略得到全面的普及与实践。
大型企业将更多地采用 DEVOPS
2016年，更多大型公司或组织最终将拥抱 DevOps 解决方案。在未来12个月内，将出现更多更为精密的工具，用于实现数据分析和问题解决依赖的关联自动化，包括跨系统基础设施智能洞察，从而降低部署共享或聚合计算、存储以及网络资源的性能风险。
作为整体战略的一小部分，全球5000强企业将不断产生 DevOps 团队。而且随着新软件和工具以及 QA 技术的使用，这一势头有望增长。我们不能那样做，因为这将破坏产品质量和安全－－－这样的日子将随着 DevOps 优势的逐步显露而渐行渐远，新的 QA 技术也可用于处理那些问题。
全球5000强企业将开始在公开论坛上谈论他们的举措以及随之而来的直接成本效益，并对其获得的成就引以为豪。虽然真正的 DevOps 对于运营着10000个应用的大型企业来说，比那些只有一个主要应用的软件公司来说更具挑战性，但这些大企业哪怕接纳部分 DevOps 文化，也能收获极大的效益提升。
2016年，DevOps 运动将开始影响传统的开发团队，他们可能还无法完全发展过渡到到真正的 DevOps 进程，但他们可以而且应该接受一些必要的 DevOps 概念。自然而然地，他们会从协作入手，继而开始更加注重终端用户、敏捷度、自动化以及测量机制。最后，也是最重要的，开始以性能为准则。
小型 IT 团队更多地采用 DevOps
2015年由于大多数 IT 环境变得日益复杂，DevOps 的受众群从小众群体和早期采用者，逐渐演变为主流公司与组织。随着2016年的到来，我们相信，正在经历开发策略文化转型的小型 IT 团队将更多地采纳与使用 DevOps 方案。DevOps 使得开发变得更加快速灵活，因此提高整个 IT 团队的效率。
DevOps 最佳实践产生
2015年 Gartner I&O 自动化技术成熟度曲线表明，DevOps 正处于期望膨胀期的顶峰。实际上在许多 IT 组织内部，只有少数处于实验阶段的应用在使用 DevOps 准则。虽然这些公司目前还未准备好将 DevOps 作为主流方案，但他们对敏捷性和快速上市时间的追求却是毋庸置疑的。预计2016年越来越多的 IT 组织将试图寻找最佳实践（理想情况下是从其所在行业的其他公司中入手）以此加速他们的 DevOps 之旅，并最大限度地减少痛苦的教训。
在软件开发领域，DevOps 仍处于新兴阶段，且该实践目前还没有明确的标准，这就导致企业犹豫是否完全接纳这种文化转型。2016年将看到各个公司建立其他们自己的标准。渐渐地，最佳实践也会出现，并应用于所有行业。
APM：至关重要的 DEVOPS 技术
2016年，我们将看到以下几大进展：开发环境进一步虚拟化和云化，甚至开发人员的工作站都将变得更加虚拟化；通过各种举措来增加单元测试覆盖率和功能测试，以实现自动捕获和监测架构指标和业务 KPI。最后，我们将看到架构重整，以使构建时间加快，部署包变小，同时更快地给工程师提供反馈。为了在这些领域取得成功，APM 将发挥重要作用。
DevOps 之自动化测试
DevOps 中的测试是必然是自动化测试，全员测试，产品经理，开发人员，测试人员，架构师等协同合作，使得测试覆盖每个方面。而且当一天上线多次时，添加补丁或者更新功能，自动化测试是保证产品测试完全的最优选择。不仅仅因为自动化测试比手动测试的速度快，它针对指定组件的所有历史测试用例都能进行迭代测试。
DevOps 中的 QA(Quality Assurance) 更多的质量保证，不再只是一些细节问题的测试，而是回归产品整体质量的保证。
DevOps 之协作开发
DevOps 中开发团队之间协作，代码提交和管理模式、测试机制、代码的交付周期、反馈和监控体系方面都要顾到，开发不再只是埋头写代码，还要为自己代码质量负责，出 bug 了，运行缓慢了如果问题定位是代码的原因，那这个坑就得自己填了。
DevOps 中由开发团队完成交付工作，不像以前开发团队和交付团队是2个团队，用各自习惯的工具，交付工作中使用的工具套件是开发流程中的工具，无需转手，简化开发测试人员的工作。
DevOps 之可视化运维
DevOps 中的一套成熟的运维系统包括什么？
自动化测试
批量配置基础组件
监控，告警
数据可视化
协同合作
一套成熟的运维系统，能够将应用、网络、计算、存储、虚拟化等资源的性能以及告警信息进行综合分析，通过简洁易懂的界面，直观呈现业务健康水平。当出现故障时，能够第一时间受到信息，从监控相关信息确定问题位置，缩小故障定位范围，确定问题是在计算、应用还是网络，进而明确问题职责，让相应的开发运维迅速处理问题，没有推脱责任之嫌。
OneAPM Cloud Insight 集监控、管理、计算、协作、可视化于一身，帮助所有 IT 公司，减少在系统监控上的人力和时间成本投入，让运维工作更加高效、简单。想阅读更多技术文章，请访问 OneAPM 官方技术博客。
===========================================
http://blog.oneapm.com/apm-tech/760.html
DevOps工具包中合适的工具可以帮助你在企业内成功实施DevOps，增强敏捷发布过程和团队协作。笔者想先声明，DevOps不仅涉及工具，如果背后没有合适的人员与文化，即使拥有最好的工具，也不能成功实施DevOps。不幸的是，没有“文化”工具可供你使用，让你能够立刻在团队之间培养协作和反馈。
合适的工具可以提供框架，帮助公司成功实施DevOps。你选择的工具，应该鼓励反馈，并防止进一步形成孤立。工具还应该帮助统一和协调团队。确定采用的DevOps工具包，是实现DevOps目标和量化成功的关键第一步。虽然工具的特性集和解决方案是很重要的，也要确保重视工具组合起来的效果。无法整合的工具可能会需要过多的维护，成本，或产生冲突的信息。
在一个非常简化的应用生命周期视图中，笔者将过程划分为四个主要步骤：规划，设计，部署和维护。在每一个步骤中，都有可以增强这一环节的工具。同样重要的是，这个过程不是一次性的，这是一个持续的循环。这种持续的反馈周期，是DevOps成功的必要基础。
与其通过一系列的产品列表来选择DevOps工具，你应该考虑自己的应用生命周期，根据特定的目标来做出选择。
基础
虽然有多款工具可以支持你的DevOps规划，但几乎每一种规划都依靠相同的基础：借助应用智能在云中进行构建。如果没有云，自动化和敏捷性几乎是不可能的——让我们在云的假设下继续。
使用虚拟化支持，在云中构建，你可以根据需求，适当调整，实现动态扩展的灵活性。云的好处是成本与需求成线性比例，所以你只需支付自己使用的部分。
要有效管理DevOps环境，你需要联合高管、开发人员与运维，并监测应用程序和终端用户的性能。不同团队和个人在一个控制台相互协作，并获得相关应用智能的访问权限，从而优化软件战略，对实现DevOps是至关重要的。
云/基础设施
Azure
AWS
Rackspace
Joyent
Cloud Foundry
虚拟化工具
VMware
Xen
VirtualBox
应用智能
AppDynamics
OneAPM
规划
开发一个新的应用，或更新现有的应用，都应该从规划开始。让开发人员了解应用的商业目标可以鼓励他们带有目的地进行思考，同时开启反馈循环。
同样，重要的是，无论你最终选择哪个工具，都应该能建立于你的应用基础之上，或与之相整合。
数据库
MongoDB
Cassandra
hBase
MySQL
PostgreSQL
Redis
搜索
Solr
ElasticSearch
Web服务器
NGINX
Apache
设计与架构
企业和开发人员经常犯的一个错误，就是在真空或孤立筒仓中设计应用程序。若没有任何反馈机制，你只是在构建自己认为有用的功能。
其实，有各种各样的工具和方法都可以优化这一阶段的DevOps开发。现有应用的实时用户监测和分析，可以有效判断客户的真正需求。它可能是一个没有必要的功能或特性，或者只是因为太复杂而没有被使用，或者有性能问题，无法正常工作。你可以监测哪些特性和功能使用得最为频繁，哪些根本不使用。最重要的是，通过分析使用量和性能，你可以识别潜在的问题。
扩展
ActiveMQ
RabbitMQ
Memcached
Varnish
部署
配置管理工具，容器和自动化测试真正改变了开发格局。DevOps的流动性和快节奏是其基础和优势之一，但它也是一个挑战，需要维持稳定的网络访问。 配置管理工具， 比如Puppet，Chef，和Ansible让企业可以管理IT配置，通过模块组件和自动化实施，从而确保持续、可靠、稳定的环境。它们使你能将基础设施作为代码。
容器
Docker
Kubernetes
持续集成
Jenkins
Travis CI
Circle CI
配置管理
Puppet
Chef
Ansible
维护
你的应用上线了，部署完成了，并不意味着你的工作就结束了。性能问题，停机时间，崩溃仍有可能困扰你的应用，进而影响业务。作为一个新的DevOps团队，你需要做好运营工作。当有问题时，收到告警，进而找到问题的根源是至关重要的，可以确保积极、无缝的用户体验。
告警
OneAlert
PagerDuty
ServiceNow
VictorOps
BigPanda
日志记录
Splunk
SumoLogic
Loggly
Logentries
DevOps是持续的，没有明确的生命周期起点或终点。这一切都始于接受DevOps文化，建立云和虚拟化的坚实基础。除此之外，规划、设计、架构、实施，部署，维护和运行应用的生命周期是一个循环往复的过程。
DevOps环境太复杂和多变，很难通过人工流程管理；使用最传统的方法监测，是无法跟上步伐的。为了有效地循环和往复，企业需要专为DevOps设计一个监测解决方案。