- 浏览: 482072 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
alvin198761:
renzhengzhi 写道我参与过12306余票查询系统的开 ...
别给12306 辩解了 -
renzhengzhi:
我参与过12306余票查询系统的开发,用户请求被前面3层缓存拦 ...
别给12306 辩解了 -
renzhengzhi:
写的很好。
JAVA线程dump的分析 -
liyonghui160com:
说好的附件呢
分布式服务框架 Zookeeper -- 管理分布式环境中的数据 -
ghpaas:
orbeon作为xforms标准的实现,不论其设计器还是运行时 ...
XForms 1.1 中文翻译—第1章 关于XForms标准
在过去的几年中,随着云计算和开发加运维现象的出现,出现了对传统的运维团队的角色的讨论,因为在当前的软件开发团队中经常会看到他们的身影。InfoQ将会深入地探究此次讨论,以更好地理解其中所涉及到的各个不同的方面,以及各种方法之间的平衡。 本次讨论的核心是这样的重大问题: 在开始关于此次争论的讨论之前,我们先是邀请了New Relic公司(基于SaaS的应用程序性能管理工具的提供商)的工程主管Bjorn Freeman-Benson和InfoQ运维社区的首席编辑Carlos Armas。然而,这只是讨论的开始,随着讨论的进行和展开,InfoQ会将最近的讨论更新到本文中,并且还可以通过关注#roleofops标签来关注Twitter上的讨论。我们希望你也参加到本次讨论中,所以请选择发布带有#roldofops标签的推特信息,或者向feedback@infoq.com发送邮件来说明你的看法,也可以在本文的评论中留下你的声音。 Bjorn Freeman-Benson: 关于改变运维的角色这个主题,已经有了大量的言论、网志以及幻灯片。在大量的交流中,人们提出了将开发和运维变得更加紧密的要求。他们称之为开发加运维或者其它术语。尽管我在New Relic公司的同事和我在总体上都持赞同的意见,但是我们认为公司应该考虑采用更具有决定性的步骤,以达到更有效的运维管理——也就是,考虑让每个开发团队都负责他们自己的应用程序的部署和性能问题。 让我们考虑一下,为什么这并非像它听起来那样不同寻常或者极端。 首先,对于应用程序,谁能比创建它的团队更了解它呢?这使得在将应用程序部署到数据中心或者云中的时候,应用程序开发团队需要与业务应用的所有者商讨,然后对应用程序进行设计、架构和编码,选择、测试并集成应用程序的各个组件(应用程序服务器、操作系统、数据库、集成中间件等等),创建原型,执行功能测试,可能还要进行负载和可扩展性的测试,向业务人员演示应用程序的功能,最终为生产环境准备就绪。几周甚至几个月来日积月累的知识怎么可能一下子就传授给运维团队呢? 开发团队应该做出重要的部署选择吗?——增加或者扩展硬件服务器,是否对服务器采用虚拟化,哪种CPU和内存是最佳的等等。开发团队应该决定他们所需要的最佳的性能监控和日志记录吗?开发团队应该监控、处理警告、把握性能和有效的时间,并且在应用程序崩溃的时候处理来自于业务部门歇斯底里的电话吗?(为什么运维人员会处理这些有趣的事儿?)我知道这种方法会有用的——在New Relic公司中,我们自己就使用它来管理世界上的最忙碌的SaaS应用程序之一。很讽刺的是,我们的SaaS应用程序耗费了将近4000个开发团队来管理他们的生产环境中的应用程序。 Carlos Armas: 这样的想法很具有吸引力,因为设计和构建系统的团队最适合对其进行运维、监控和扩展。由这个逻辑递推,我主张开发团队应该负责处理公司的账务,因为软件开发者都很擅长处理数字,或者由于他们对环境很关心,因此应该在工作之后清理办公室并将垃圾箱倒到外边的回收处。这样做就忽略了几百年来的重要实践:分工。事实上,开发团队比其他人更加了解应用程序,但这并不能成为要他们负责对发布到生产之后的代码进行运维和维护的原因。 我假定自己是公司所有者的角色,并给出三个原因,说明为什么我不想这样的事情发生在我的公司中: 1)财务上的:软件开发者的平均工资总是要比运维支持工程师的高。作为公司的所有者,为什么我想要让我最昂贵的团队做运维任务呢,那种任务可以由其它团队完成,那样更节省资金,更有效。在任何敏捷团队中,任何好的Scrum教练都会告诉我们,他们的主要任务之一就是移除障碍,并让隐藏的工作可见,从而开发团队能够更有效地开发代码。为什么我想要将更多的障碍和额外的工作强加给开发团队,从而降低他们的效率呢? 2)质量:我相信检查和平衡,因为没有人是完美的。当团队负责应用程序完整的生命周期时,客户最终要吞下这个苦果:很差的用户体验。当开发代码的团队同时也负责决定其质量是否符合发布标准的时候,那么发布不完善代码的风险就会大大提高。拥有完整的生命周期使得人们自满,并会滋生“我们总是可以在生产环境中修改它”的错误想法。 作为公司所有者,我更喜欢对系统进行检查和平衡,从而我们可以更好地服务客户,并因此得到他们的回报: 实质上,我希望质量是大家分享的责任,各个团队对于非常特定的区域和责任相互负责。我希望团队之间的关系是一种积极的矛盾,从而为持续的质量改进提供动力,并且在头脑中将客户作为唯一的目标。 3)机会的浪费:如果软件开发团队忙于运维工作,那么谁会开发新的特性并改善应用程序呢?谁来修复软件的缺陷呢?开发者会和生产团队会仅仅因为一个页面跳出来,警告他们Amazon EC2的一个实例出错,而被滞留在下一代软件的设计过程中吗? Bjorn Freeman-Benson: 其次,当应用程序被部署在云中时,运维的真正任务是什么呢?越来越多的网络应用程序被部署在公有或者私有的云架构中。在New Relic公司中,超过40%的客户将应用程序部署在云中,并且我们期望这个比例在2010年末会很大。就算大部分公司都比较小,没有大公司需要处理的遗留数据中心或者数据整合的麻烦。但是,每天我们还是会与新的客户签约,他们可能是带有传统数据中心的大型组织,而客户的应用程序被部署在Amazon或者其它公有云中。 那么,在这些情况下,运维团队应该扮演什么样的角色呢?他们不会负责云的硬件、网络、电话。他们不会对架构监控做出选择。在云中唯一属于他们公司的就是应用程序的代码本身。其它所有的一切都是由云架构提供商负责的。因此,坦率地说,当我的应用程序被部署在云中,谁会需要运维团队呢?开发团队必须负责基于云的应用程序能够成功执行。除了他们,谁也做不到这一点。 Carlos Armas: 很有趣的是,看起来似乎人们期望云中的系统能够自我管理,那是错误的认识。让我们退回几年来说明这个问题,并讨论一下托管服务。 我们当前所知的托管服务是从托管提供商意识到他们可能会为客户提供硬件和带宽之外的服务开始的,并且在他们的服务组合中包含了系统管理和对应用程序的管理。结果显示那是很棘手的业务,很难保证交付时的一致性和良好的质量。只有少数提供商做到了这点,但是付出了很大的代价。 从上面的观点中,云计算将系统管理和应用程序管理任务推回给了客户。(我们不想在此定义云计算,那肯定会导致另一个讨论:)) 那么运维团队在云中应该做什么呢?首先是系统管理。然后是应用程序的部署、监控、发布扩展和响应。我们仍然需要24x7的电话支持,因为系统位于云中。系统管理(针对Unix、Linux、Windows等等)是开发者无法做好的事情,因为他们并非是该领域中的专家,就像系统管理员不是好的软件开发者或者好的市场人员和沟通执行者一样。 然而,随着(并且如果)云计算变得越来越普遍,运维团队的组成也逐渐产生了变化。你之前提到了硬件、电信和网络。显然对这些能力的需求会从云客户的公司转移到云提供商。客户还是要保留系统管理员角色,并且会和之前一样需要(甚至更加重要),因为提供商不再为你管理虚拟服务器的操作系统。(记住,作为公司所有者,我想要软件工程师开发代码,Scrum教练防止他们做隐藏的工作,同时还要排除他们工作进程中的障碍) 我们还可以认为,在这样的场景下,运维团队不再存在,而运维工程师变成了软件开发团队或者其它团队的一部分。那是有可能的,事实上当前在小型团队中正是这样。然而,我不认为我们在这里是在关注组织结构图,而应该关注在合并的托管技术环境中运维和开发的角色。 本质上,我的观点是,软件开发团队不应该负责运维任务,并非是因为他们不能,而是因为那在财务上、组织上和商业智慧上是不合理的。 此外,当提到云的时候,你说:“看起来似乎人们期望云中的系统能够自我管理,那是错误的。”是的,很明显云架构不会自我管理。但是我们所说的是与云相关的系统管理工作是由云提供商完成的。因此我说如果我们在将应用程序部署在云中的公司中做IT工作,为什么还需要系统管理员呢?我们应该让开发者来做大部分应用程序管理工作,这样就不需要再建立云团队了。如果一个公司使用的是云平台——RightScale、Heroku、Stax、Gigaspaces、EngineYard等等——中的一种,那么大部分的与系统管理相关的工作都是由平台自动完成,而不是由系统管理员人工完成的。 让我给出另一个观点,来说明为什么开发者应该对生产环境中的应用程序负责。谁能够比编写代码的团队更好地找到性能问题的根本原因呢?假设运维团队得到了应用程序的性能出现了问题的警告,可能来自于性能检测工具,或者来自于不可避免的业务人员的电话,他们在其中大发雷霆。典型的运维人员能做什么呢?如果他们极度幸运,那么可能会将产生问题的原因隔离到一些出现问题的架构中。坦率说那种情况十分少见。通常运维人员所使用的各种架构监控工具会显示一切“绿灯”。往往问题都在于应用程序之中。谁能比开发团队更知道在虚拟机中发生了什么呢?大多数运维人员都不是开发者,他们不会读代码,也不能跟踪原因隐藏在程序中的问题。为什么需要运维团队作为中间人来接受警告,然后他只是将问题转交给开发团队?还是让开发人员来接受警告并更快地着手解决问题吧!如果问题在于他们的代码之中,那么他们就应该是修改该问题的不二人选。这样做额外的作用就是让开发者对于他们发布到生产环境中的代码更尽心,因为知道他们需要对结果负责。 以下内容增加于4月19日 Carlos Armas: 是的,我当时是在开玩笑,:) 我发现使用幽默更便于沟通和理解。我越是阅读你的评论,越是觉得似乎我们的观点并非是像旁观者乍一看所感觉的那样针锋相对。 我同意开发者能够学习并执行很多运维任务,这是肯定的。但是请记住,我还是希望他们能够专注于代码,将该项工作放在第一位,正如我坐在公司所有者的位置而谋其事一样。我在下面陈述你所作出的非常重要的观点时,会再回头来看这个观点。 在此有一个很不固定,并且正在发展的概念:云计算。如果你让我给它下定义,我可能会逃之夭夭。(我可不想作为现代云计算的布道者来吸引眼球) 可以说云计算是个宽泛的概念,它关注的是需要最少或者可能根本不需要运维专业支持的服务(Heroku,以及其它等等)。它还涉及到像Amazon的EC2、Rackspace的RackspaceCloud、Opsource's的OpsourceCloud等服务,其中涉及到大量运维工作,这依赖于所要支持的应用程序的种类。 所以这件事的问题在于,“具体情况具体分析”。 我对你的观点的根本原因进行了分析,在提出我的反对观点之前,让我先强调一下你的一些我观点: 如我所见,如果开发者开始做运维的工作,那么: 基于实战的经验,我要对上面的观点表示反对: 对我来说有些事情已经很清楚了:冲突是切实存在的,但是如果不熟悉信息技术实践的历史,那么就很难梳理出为什么我们因此而受苦的原因。我有一条未经测试并且非常单纯的理论:变更对于运维是有害的,而软件开发就是变更。因此存在最重要的矛盾,这需要聪明地处理。 新从公司所有者的角度来阐述,因为我要花费资金来试图提供管理冲突的过程(是聪明的吗?)。我要使用敏捷的用户故事方式来说明,作为公司所有者,我想要: 本质上,我还是想让我的软件开发团队编写代码,构建新的特性来吸引客户的眼球,而不能被其它任何事情来分散精力(包括云计算)。我还是想让运维团队(或者是拥有多名工程师的团队,或者是兼职的远程系统管理员)来调整系统,并能够对构建客户想要的东西的团队做出最快地响应。我还想让运维团队学习应用程序层的关键知识,那样他们就能够不定期地找到针对架构的缺陷(作为唇齿相依的关系,不再对变更抱怨)。 以下内容增加于4月20日 Bjorn Freeman-Benson: Carlos,多谢你明确了立场。简要地说,我同意大多数你关于开发者如何认识运维人员的说法(变更阻碍者),并且我想要增加对运维人员如何对开发者的认识(一群疯狂的牛仔)。我看到,关于我们的讨论,有很多读者发表了有意思的评论。我已经在线下得到了一些关于影响的反馈(感谢@markimbriaco和@randybias),我的立场很明确,强烈地反对运维功能。我并非故意如此,并且希望我没有将运维人员描述为完全不必要或者没有能力。我并不认为没有公司需要运维功能,很显然并非如此。 我的立场和观点都集中于应用程序,以及对它们负责的人。毕竟,如果不是为了应用程序的开发和运维,IT还有存在的价值吗? 让我用这次发布的内容来澄清我的观点,并对Carlos上面的一些评论做出回应。 首先,我所听到和读到的来自于运维人员的讨论(其中很不错的一条评论就在本文下面,由John Willis发表)告诉我们,没有人知道,运维的角色已经产生了很大的转变,这比运维人员本身还要大。Carlos,你的评论也显示出这一点。他们能够认识到,数据中心和应用程序比起几年前已经有了很大的改变。数据中心过去会是各种技术的大杂烩——一台大型机、一些AS-400机器、一些RS-6000机器、一些DEC的小型机以及一些“那些web家伙”使用的Wintel服务器,再加上一大堆存储设备,他们需要不时地对其进行维护和反馈。现在仍然还有这样的数据中心,对于支持它们的运维团队,我想可能没有什么变化。然而,现在数据中心里面拥有1000台Linux/Tomcat的刀片服务器已经不是什么稀奇的事儿了,所有这些刀片服务器都彼此相同。另外,几乎所有应用程序都基于Web技术(Java, .Net, Ruby, PHP)也不是什么稀奇的事儿,并且在那些数据中心中没有什么需要学习的管理工具,也没有需要支持的专利系统。云计算将这种现象发展到了极致。因此在越来越多的情况下,运维团队的角色由于标准化和便利性而越来越简化。我们的观点是,我描绘的情况正在成为标准而不是不常见的情况。 即便是在高度标准化的数据中心(我的有1000台刀片服务器的例子中)情况下,仍然还有运维的任务。有大量需要专业知识的工作——数据库管理、容量规划、数据备份和恢复、灾难恢复规划、电力管理、通信管理等等。执行这些任务的人是为整个数据中心在服务(或者是为雇用他们的云提供商)。 我的观点的关键在于,对应用程序的管理职责应该主要归属于应用程序开发团队,而不是运维团队。另外,Carlos(这可能会让你感到惊奇),我完全同意你下面的观点: 我的观点是,开发者和架构师能够比运维团队更好地为部署、监控、以及突发事件管理决策做准备,因为他们拥有与应用程序架构和语言最紧密相关的知识。在应用程序管理的情况下,运维和开发团队之间职责的划分没有那么有效。谁应该为应用程序的成功对公司负责也不是很清楚。最终,通过把应用程序的进展管理直接放到开发人员的工作描述中,应用程序的质量会得到改善。我们不再允许开发者向运维团队发布代码质量低的应用程序,然后对后来的烂摊子放手不管。 我喜欢你针对“公司所有者想要的是什么”的敏捷故事方法,但是在对其作出评论之前,我想听听来自于读者的评论。 以下内容增加于4月21日 Carlos Armas: 尽管我非常愿意相信运维团队的任务正在变得简单(这也是我所期望的),但实际的情况却恰恰相反。 据我所知,在过去的15年间,人们误解了运维任务,并逐渐将其最小化了。不必感到奇怪,因为这很大程度上都是运维团队的错。 这开始于大型机时代,当时MIS(信息系统经理)担任的还是“计算教堂中的神父”的职责。在“机器时代”,玻璃墙后的评判者使用仪式、保密和分离的原则进行运维工作。这对于监视很有好处,也有利于在公司竞争范围中对挑战进行控制。 那样的时光已经一去不复还了。正如我所见,工作中最简单的部分已经逐渐地消失了。我们不再通过分离/bin和/usr/bin目录来对硬盘进行加速和减速,或者使用12GB内存的Sun E4500,让它占据数据中心最重要的位置。我忘记了是什么时候我最后一次使用剥皮钳来做电缆(谢天谢地!)。我也不再记得曾经是什么时候不得不编译一些程序,因为apt或者yum会给我稍微旧一些的、无法处理的版本。 我认为运维的物理任务很早以前就从我们的工作描述中消失了,而被放到初始化/支持任务中。另一方面,我们的工作变得越来越复杂。多服务器的同构数据中心(甚至是虚拟的、“云”的)带来了不同的、更高级别的让人头疼的工作和复杂度。随着kickstart,puppet,以及其它相关的自动部署机制一起,所谓的“原子任务”也随之而来了。在单一服务器中的简单拼写错误/etc/sudoers很容易修正——但现在在我们的系统中存在自动的乘法/加速效应,那会让错误在几秒到几分钟内扩展到成千上万台服务器中。 每天我们面临的挑战也发生了变化,从“为什么编译失败?”变为“怎样我才能骗过傀儡模块,它将应用程序Y部署到120台服务器上来安装发布X,但是在完成之前无法发布X+1,所以最终我没有在生产实例中发布alpha测试质量的代码”。我很喜欢现在的情况,因为“现实世界中的约束”不会成为云提供商的环境中的障碍。协商、斡旋、统筹、分离和配置工作都应该提前做好。那就是过程。这个趋势为云计算铺平了道路,并且肯定会很受欢迎。而我的工作肯定不会变得更简单,尽管我使用自动化的方式来帮助我更好地铺平了道路。 我们可以这样认为:它变得更加复杂,但现在我拥有更好的能为我们提供帮助的工具。并且,作为通向下一个目的的途径,我非常感谢创建这样的自动化工具的开发者们,那也是我想要它们一直为新的想法做开发,而不是管理部署后的应用程序的原因所在。 我同意你关于开发人员和架构师的观点,他们正在准备更好地做出部署/监控/突发事件的管理决定。毫无疑问,在我的意识中,开发者和架构师比任何人都更了解它们所创建的应用程序。 对于谁应该为公司对应用程序的成功负责这个问题,我仍然持这样的观点(可能是过时的),应用程序是服务生态圈中的一部分,没有支持它的架构基础就无法生存——即便是在云环境中,架构也需要管理,我更希望在该领域非常专业的人来执行那些任务。我想可能是看问题的角度的问题,我们更可能在此通过同意的方式来表达反对。 现在,让我们回顾一下开发者在他们的工作描述中增加对应用程序在生产环境中的管理的责任,正如你所提到的:我喜欢!非常喜欢。“放轻松一些,年轻人”。将你的开发者轮换到运维团队的岗位,从而他们能够得到交付一致的、24/7 SLA支持的用户体验相关的需求和挑战的第一手经验,同时给他们灌输应用程序级别的知识。这和新雇佣的开发者一样的。作为对等(反击),我会将我的运维工程师轮换为你的SCRUM团队,并且体验第一手的“排除障碍”的工作,由于延迟和红色条所带来的挫折等等。这对于消除团队之间的(人为的)壁垒非常有益,那样就不会再有“我们 vs 他们”。 上述的内容会确保我让开发者做的是我需要他们做的(作为公司所有者):创建新的功能,同时有助于传递知识,从而能够在生产环境中更有效地支持应用程序。 以下内容增加于4月27日 Bjorn Freeman-Benson: 这是非常有趣的一周。很抱歉我已经有好几天没有发表内容了。我在我们的SaaS工具上部署了很棒的新特性,并且开始了下一轮的开发。现在我们在应用程序性能监视工具中包含了对生产环境的概要分析。我们至少每周都会推出一些新特性,并在一周之内做几次ad-hoc的补丁。这让我们一直都很忙。我还要说,在New Relic,我们仍然拥有非常棒的系统管理员,他叫Bayar Carlin。我知道,通过我的评论,你可能会认为我们没有任何运维人员。但是,我们确实有一名。他也是应对我们的员工的需求的内部IT部门。在以后的内容中我会更多地谈到Bayard。 在查看来自于读者的一些评论的过程中,我看到了很多非常好的评论,想在这里强调并做出回应。在下次发布的内容中,我会总结从所有这些反馈和Carlos的观点中所学到的东西。 首先,David Sims评论道:“让我们的开发者深入参与到技术支持中真的很好,因为这让他们产出了更好的产品。然而,正如Carlos所指出的,作为小公司的所有者,我知道让开发者来回答问题并非是对资源最有效的利用,有技能的支持工程师同样可以处理。”我对两位的意见都表示同意。我已经看到让开发者参与到生产环境的会让产品质量得到稳步地改善。我们也同意David的意见,他说对于开发团队,当还有新的代码要写的时候,花费时间做运维的工作是一种挑战。然而,如果David的意思是运维工作并不具备足够高的价值,那么我就要表示反对。我不会为运维团队所做的工作分配比开发团队做的工作少的价值,只是之间有所不同。 其次,Geva Perry关于云计算造成的影响以及对运维的角色的影响的分析的思考非常有价值,可能某天我们会在新的文章中对其进行扩展。在New Relic中的一些应用程序位于云中,而另一些位于传统的托管环境中。然而,我们有大量的客户,部署在各种各样的云环境中,我们听到其中的某些客户谈到,他们在新的部署环境中遇到了很多新的、不同的需求。 第三,我对John Allspaw的评论同时持同意和反对的意见。我不同意他所说的(云中的)自动化不会明显减少运维人员的数量。我认为这是不可避免的趋势。我同意在大多数大型的公司中,仍然还会与运维团队,并且我们可以用他们学会协作的程度,而不是抹杀他人的成绩的程度来衡量成功。 第四,我喜欢Sellers Smith的意见,“健康的运维环境的标志”。我认为他处于正确的轨道上。我还是喜欢将应用程序和服务等级中更多的责任成功地迁移给开发者,从而在开发人员和运维人员之间没有过多的传递,而有更多在思想来创建应用程序和应用程序平台。想一下在工业工程和客户产品中的对可维护性的设计的运动,你就会明白我所想要表达的意思。 下次发布时我会总结我所学到的,并继续征求你们的意见。 以下是最近与本次讨论相关的Twitter评论,你可以在此查看: searching twitter... 上面的Twitter工具是免费的、开源的、基于Javascript的库,你可以在此找到:http://tweet.seaofclouds.com. 查看英文原文:Debate: What is the Role of an Operations Team in Software Development Today? [Updated Apr 27th]谁应该负责对生产环境中的应用程序进行管理、监控和运维?
我有一条未经测试并且非常单纯的理论:变更对于运维是有害的,而软件开发就是变更。因此存在最重要的矛盾,这需要聪明地处理。
发表评论
-
高性能、高流量Java Web站点打造的最佳实践
2013-12-24 11:23 2812从2005年-2013年,Ashwanth Fernando ... -
高性能、高流量Java Web站点打造的最佳实践
2013-12-24 11:01 4从2005年-2013年,Ashwanth ... -
20行实现javascript模板引擎
2013-12-23 10:35 150820行实现javascript模板引擎 我仍然在用Abs ... -
标题怎么办
2012-03-25 23:50 21.首先在这里 下载Selenium RC,解压到C盘。 ... -
Google Page Speed应用上线,移动设备也在支持之列
2011-04-05 21:23 855Google已经将Page Speed应用到线上,并且加强 ... -
浏览器的加载与页面性能优化
2011-02-16 11:23 1315本文将探讨浏览器渲染的loading过程,主要有2 ... -
门户网站负载均衡技术的六大新挑战
2010-12-23 11:25 995文 / 李晓栋 记得上 ... -
使用 JAWS 测试 Web 应用的技巧
2010-10-31 23:34 1633屏幕阅读器简介 屏幕阅读器(S ... -
How We Evaluate the Experiences We Engineer
2010-10-26 14:38 7159 and how we measured (and co ... -
研究显示:众多网上零售商未遵循Web优化基本准则
2010-10-26 10:25 696Web优化专家Joshua Bixby最近在博客中披露,在 ... -
Testing sites with Browser Mode vs. Doc Mode
2010-10-22 10:07 1066With site developers verifying ... -
Common Security Mistakes in Web Applications
2010-10-22 10:02 1693Web application developers toda ... -
A (somewhat) brief history of the performance landscape
2010-10-21 10:44 1710I’d like to enlist your help. ... -
Best Practices for Speeding Up Your Web Site
2010-10-20 10:40 1205Minimize HTTP Requests tag: ... -
Web Performance Optimization Use Cases – Part 1 Benchmarking
2010-10-19 14:40 939Web Performance Optimizatio ... -
Google WebP——让图片更小,让页面访问速度更快
2010-10-12 13:14 1586Google日前对外宣布了一种新的图片压缩格式WebP,可 ... -
剖析IE浏览器子系统的性能权重
2010-09-02 13:23 873最近,InfoQ中文站报道了Web 2.0应用客户端性能问 ... -
Performance: Profiling how different web sites use browser subsystems
2010-09-02 00:41 1205When we first showed IE9 at t ... -
Measuring Browser Performance: Understanding issues in benchmarking and performa
2010-09-02 00:40 945Measuring Browse ... -
Ajax应用开发:实践者指南
2010-08-10 21:13 977目前的Web应用开发基本上都是围绕富互联网应用(Rich ...
相关推荐
然而,在实践中,很多企业的组织架构仍然沿用旧模式,没有为运维团队提供明确的角色定位和职责范围。这不仅限制了运维团队的发展空间,也影响了其工作效率。 ##### 4.3 缺乏有效的沟通机制 开发团队和运维团队之间...
### 项目移交清单详解 #### 1. 项目文档 - **内容**: 包括但不限于项目计划...通过以上详尽的项目和运维移交清单内容,可以有效地帮助新团队快速熟悉项目和运维工作,确保平稳过渡,同时减少因信息不对称导致的问题。
在这个活动中,一个重要的议题是【iDevOps - 系统开发和运维】,这体现了IT行业对DevOps理念的重视,它旨在通过开发(Development)和运维(Operations)团队的紧密协作,提高软件的交付效率和质量。 DevOps是一种...
这些框架的目的是为了缩短软件开发周期,提高产品质量,同时减少运维工作中的错误和风险。 首先,DevOps的核心是团队间的协作与沟通。通过跨职能团队的紧密合作,开发人员和运维人员可以更好地理解彼此的角色,从而...
软件系统发布上线流程是软件开发过程中至关重要的环节,确保软件产品在投入实际生产环境前的质量和稳定性。这个过程通常包括提交测试、预热发布、正式上线和应用服务监控四个主要阶段。 **一、提交测试** 1. 开发...
- **DevOps的指导框架**:DevOps强调开发与运维团队之间的紧密协作,旨在加快软件的交付速度并提高质量。敏捷方法作为DevOps的重要组成部分,提供了实现这一目标的具体路径。 - **开发运维一体化**:通过持续集成/...
敏捷开发和DevOps都是现代软件开发中不可或缺的实践方式,它们分别解决着不同的问题并相互补充。敏捷开发强调的是以人为中心、迭代和渐进的方式进行软件开发,而DevOps则致力于消除开发与运维之间的壁垒,实现快速、...
DevOps,即Development(开发)与Operations(运维)的结合,是一种旨在促进开发、测试和运维团队之间协作与沟通的软件开发方法论。它强调快速迭代、自动化流程和持续改进,以提高软件质量和发布速度。 报告指出,...
在当前互联网行业迅猛发展的背景下,敏捷开发模式逐渐成为软件开发团队推崇的开发流程。敏捷开发中的测试工程师角色也发生了巨大的变化,承担着更为重要的责任和职能。平安金服的陆怡颐在一次演讲中深入探讨了这一...
这有助于工程师在职业生涯中不断进步,提高解决问题和团队合作的能力。 六、系统篇 系统篇主要探讨系统设计和架构,包括高并发、大数据处理、分布式计算等复杂场景的解决方案。可能讲解了如CAP理论、设计模式、数据...
鉴于此,我们将基于文件的部分内容,探讨软件工程中的可行性研究及其关键概念,从而间接关联到Visual C++ 6.0作为软件开发工具在可行性研究中的应用。 ### 软件工程中的可行性研究 #### 可行性研究的目的与意义 ...
例如,在软件开发团队中,可能关注的是代码质量、开发周期、bug修复速度等。通过持续跟踪这些指标,管理者可以评估团队的表现,制定有效的改进策略,以实现团队的持续成长和公司经营目标的达成。 总的来说,管理学...
在当前的IT行业中,云管理平台扮演着至关重要的角色,特别是在大规模软件开发和运维中。标题和描述提及的“行业文档-设计装置-云管理平台代码生成与回收的系统与方法.zip”是一个聚焦于云环境下的代码管理和生命周期...
- 开发过程中,代码会上传至版本控制系统(如SVN),便于团队协作和版本控制。 - 测试阶段涵盖多个方面,包括模块测试、接口开发、合规性开发等,以确保系统的稳定性和功能性。 - 系统测试和联调是验证系统功能...
3. **软件开发流程**:讲解从需求分析、设计、编码、测试到上线运维的全过程,使学员理解软件开发的各个阶段及其重要性。 4. **云计算与大数据**:随着云计算和大数据技术的普及,理解这些技术的基本原理、应用及其...
此外,书中也讨论了DevOps文化在促进架构设计与运维之间协作的角色,强调了整个团队对产品质量的共同责任。 在实际案例部分,作者通过具体的项目经验,展示了如何将敏捷思维应用到不同的架构设计场景中,包括从传统...
在当前的IT行业中,DevOps已经成为了企业提升软件开发效率和质量的重要手段。"DevOps需要敏捷教练2022DevOps顶级峰会(脱敏)"这个主题表明,这是一个聚焦于如何更好地结合DevOps实践与敏捷方法的高端研讨会,旨在探讨...
首先是应用的更新,这是在软件开发周期中频繁发生的活动。利用Docker容器的特性,可以实现零停机时间的更新。即在容器内部进行更新时,不需要停掉服务,新的容器可以立即启动并开始工作,老的容器在新的容器完全就绪...