自动化东莞网站建设,怎么做淘客网站推广,pc端自适应网站模板,手机搜索引擎排名一、技术团队细分及配合问题 在IT企业里产品从创意到交付给用户#xff0c;从整体上看是由技术部门负责#xff0c;但如果深入到技术部门#xff0c;会发现由不同的技术团队负责不同的部分或者阶段。一般会 分产品团队、开发团队、测试团队以及运维团队#xff0c;在互联网…一、技术团队细分及配合问题 在IT企业里产品从创意到交付给用户从整体上看是由技术部门负责但如果深入到技术部门会发现由不同的技术团队负责不同的部分或者阶段。一般会 分产品团队、开发团队、测试团队以及运维团队在互联网公司里运维团队一般还分基础运维和产品运维两个团队基础运维负责基础设施(包括机架、网络、硬 件)和操作系统的安装为整体公司的所有产品提供基础设施的运维服务。而产品运维负责线上产品的问题处理、代码的布署和跟开发的接口等。 不同的技术团队一般隶属不同的部门分散在公司不同的办公区域团队内部的沟通相对多一些但团队之间的沟通较少。不同团队都会形成自己的办事习 惯、节奏都有自己的关注点一般只是知道与之接口的团队的总体职责但是不知道对方可能面临的困难与工作中的挑战点。另外如果公司够大每个团队内部 又会分为许更细的小团队如基础运维一般有系统团队、网络团队和IDC团队等这样更加重了团队之间沟通难度。 从产品策划到上线一般是以下边的顺序经过各个团队 开发团队收集产品的需求定下时间表并进行开发开发完后交由测试或质量团队进行测试然后交给运维团队布署新产品或新版本运维团队将运维过程中发现的代码缺陷反馈给开发团队进行修复在上面的每个阶段对应的团队都是各做各的一般是在最后才会把球踢给下一个团队如果下一个团队发现问题又会把球踢回原来的团队。如果你深入到不同的团队中去或听到不同的抱怨声音。 基础运维团队经常抱怨 产品开发一点计划都没有突然要上线机器让我们措手不及。每个产品都急着上线谁催得急就上谁的谁能说一下到底那个重要动不动就要重装系统坏了一块盘就着急去修刚从机房回来又要过去。上线太突然了没有交换机没有机架还需要搬别的机器腾地方。那个地方有机架和交换机端口但没有四层设备他们又要放在四层后边真的没有办法了。刚跟他们上线到一个机房他们又说要换到另一个机房尽折腾。他们怎么能那么用设备把上连端口带宽都跑满了。产品运维团队会说 真没办法上个线不是说没机架就是没有交换机还有就是说没有四层设备。从来不告诉我们什么时候能设备能上线交付给我们不派专人催着这事一点谱都没有。本来没有想好怎么用这些设备先提前一个月申请上线得我们想清楚了他们却说又得换机房。网络怎么老是出问题他们怎么规划的。开发的代码太不靠谱一上线就引发用户投诉只能回滚到老版本。开发人员的技术能力不行写不出能用的版本。开发要求有一个跟生产环境一样的测试环境这不可能有的。而开发团队却说 他们又不让我们碰线上的系统生产环境是什么样我们都不知道没法开发代码。我们辛苦开发几个月上线出问题又直接回滚了心情很不好受。代码在测试环境或我的机器跑的好好的呀怎么一上线就出问题呢。测试怎么测的那么多问题发现不了。我们希望产品运维同事帮忙搭一个跟线上一模一样的测试环境。另外测试团队的人也许会说 开发人员不写规定写单元测试代码。想着能用一个自动的集成测试环境因为开发的原因老是实现不了。测试环境跟生产环境不一样好多问题才发现还有那么多的bug没有解决产品就催着上线。二、技术团队之间配合不好的影响 上面看到的团队之间的冲突和抱怨问题虽然都不一样产生的影响确是类似的 产品上线的进度延误整个团队很难正常交付新版本。产品上线后问题很多影响用户的访问。团队的士气很差。最近又发生了运维团队与开发团队之间的配合不好的问题影响及原因如下 新产品上线延误了两个星期正常情况下一天就可以上线。原因是开发考虑不周测试环境中没有发现到上线前才发现部署到多台机器上后按开发原先计划的方式多台机器无法协作完成任务。还有就是在设计阶段没有考虑生产环境的状况在上线的过程中需要做出对应的代码调整。上线后质量不稳定出现多次紧急修复。原因同上。临时增加硬件投入。新产品中有个组件采用全新的技术方案跟原来的LAMP体系不兼容所以需要新增机器单独部署。除低了服务可用性标准并产生了遗留问题。因为临时需要增加硬件而恰好又只有一台这样就形成了单点如果该机器出现故障服务将全部 中断。另外由于开发前设计上考虑不周跟别的组件集成时产生别的单点。所以这些降低了服务的可用性以后还得想办法解决。除此之外组件采有新的软件 安装、服务起停以及软件配置的管理都是纯手工打造以后还得找时间纳入到自动配置管理中。影响了团队士气。在上线过程中开发、测试和运维都觉得不舒服相互之间产生了抱怨。如果不处理好会影响以后的配合。虽然有些问题确实需要靠某些团队提高自身的人员技能才能解决好但这些团队能够形成一股合力的话同样的人员组合肯定会产生更好的效果。 三、过去解决团队配合问题的方法 第一次碰到团队之间的配合问题时我们还没来得及解决的时候公司战略调整整个开发和系统运营团队转给了另一个大部门。但我们在别的地方重新梳理技术团队时后来又没有出现这种问题回想起来我们的做法是 部分开发人员有生产环境中服务器的帐号可以观察代码的运转情况少数核心开发人员还有sudo权限当然他们也不会随便修改服务器的设置开发时一开始就会跟系统运维团队沟通在代码中增加数据收集的接口和监控接口这样上线后很容易收集产品的性能数据并能方便地对运行状态进行监控与报警生产环境中也有沙箱与beta环境这样大的版本从测试中过渡到生产环境前先在沙箱环境中适应一段时间这样能相对平稳过渡到生产环境部分开发人员临时转到系统运维团队工作一到二个季度跟系统运维同事一起上线产品解决产品在运行中发生的问题这样更好地了解代码如何在生产环境中运行回去之后能更好地运维同事沟通开发出来的代码更容易在生产环境中运行这样不同团队之间虽然有职责上的明确分工但在中间的配合的部分做了不少柔性处理。另外开发、运维与测试等团队中的核心人员之间本身就有认同 感大家一开始的目标就是奔着公司能成功来的这是没有出配合问题的根本原因。这一点其实跟DevOps的核心点类似既然如此何不重新审视一下 DevOps并参考着解决团队之间的配合问题呢。 四、DevOps DevOps是2010年从欧洲传过来的概念最先是由一群有着跨学科技能的工程师提出来的为了解决下面的问题 推出新功能和解决老问题的周期过长新产品或新版本上线充满风险代码能否在生产环境中稳定运行没有人有信心只能艰难地推上去再看是不是有问题不同团队相互隔离配合差。如开发人员收到问题后第一反应是“在我的机器上工作得好好的呀”我认为DevOps的核心是不管你是开发者、测试人员、管理者、DBA、网络工程师还是系统管理员大家都是一起的只有一起努力给客户提供稳定而高质量的软件服务实现公司的商业利益才会有别的包括自己的工作机会。 所以DevOps实际是给各个团队之间搭桥让他们不仅仅是依靠上线申请单这样的鸿雁传书工具进行沟通而且经常离开自己的孤岛走到别人的岛上去了解别人并提供自己的想法帮助对方。 DevOps更象是一种运动每家公司都需要根椐自身的特点进行借鉴推动团队之间的协作与合作。需要在三个方面努力 人员一方面对现有人员进行培训鼓励他们了解别的团队的工作、面临的挑战等让他们用自己的特长去审视和帮助别的团队另一方面也想办法招一些全面的技术人才在不同团队之间搭出一些适用的桥来。流程在研发的前期让系统运维同事参与起来一起搭建测试环境验证想法或者也可以在一些项目团队中直接配有系统、开发和测试以及产品人员 一起为产品的上线努力。出现问题的时候一起想方法找到问题的真正根源避免相互推托将解决方案落实在以后的研发过程中。从绩效考核流程上也需要考虑协 作因素。工具说实在的大家针对DevOps在工具方面其实讨论得更多这里面跟敏捷有些类似之处。快速的系统部署和自动化产品代码发布方面的工具显得尤为重要了。为了避免校弯过正走向另一个极端也需要避免下面的对DevOps的常见误解 DevOps意味着要给开发者root权限可以给开发者加sudo权限运行指定的命令比如重启web服务。让开发者更多地了解生产环境和产品的运行状况但并不意味着让开发者象管理员一样的去管理机器。所有系统管理员需要写代码所有开发者需要上架机器在系统管理和开发者各个领域仍然需要各自的专家如存储、网络、安装、javascript等专门的人才DevOps并不意味着让大家不做自己专长的事情。你一定要用某个工具不然就不是DevOps一些技术和自动化的工具对推动各个团队之间协作很有帮助但是还是需要聚焦于要解决的问题根椐问题和组织的特点选择合适的工具。我们需要招聘DevOpsDevOps不是一个新的岗位五、结合DevOps解决团队配合问题 管理人员关注团队之间的沟通机制及氛围 以新版能在生产环境中可靠稳定运行为目标形成协作的氛围。在项目的早期立项之间运维、开发与测试就进行沟通可能的话坐在一起面对面沟通。在项目上线前除了测试功能还要关注部署、备份、监控、安全以及配置管理在早期发现的问题越多越能尽少后期的问题并避免影响用户体验。建立各个团队的核心成员定期沟通机制。团队之间的协作纳入绩效考核过程中去。让开发人员了解运维工作、关注点及挑战并从开发视角帮助运维 开发人员参与运维团队的内部培训了解线上的系统。了解运维如何定位并解决故障、如何监控系统的运转情况等。少数开发人员可以跟运维一样发版本到生产环境中让开发人员关注并了解自己代码的运行情况。从运维的视角修改代码方便运维人员进行日常的变更与调整监控与报警。帮助运维人员修改puppet配置模板。帮助运维人员编写与修改产品的发布脚本提高自动化水平。让运维人员了解开发过程的关注点及挑战并从运维角度改善开发过程 运维为开发在公司搭建基于虚拟机的测试环境虚拟机的安装、配置管理以及代码的发布采用跟生产环境一样的方式。开发人员与测试人员象运维一样发布版本到测试环境中。鼓励开发与测试人员修改puppet配置与模板管理自己的虚拟机。在生产环境中建立了beta环境开发人员可以直接发版本上去让代码在最终上线前多一层缓冲。运维去了解代码的模块结构从运维的角度修改代码让产品上线后更方便运维与适应生产环境的特点。运维参与到持续的集成测试中用自己的自动化知识帮助实现自动的集成测试等。
