登录以解锁更多InfoQ新功能
获取更新并接收通知
给您喜爱的内容点赞
关注您喜爱的编辑与同行
966,690 十月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
讨论：当前运维团队在软件开发中的角色
讨论：当前运维团队在软件开发中的角色
Ryan Slobojan
0&他的粉丝
0&他的粉丝
日. 估计阅读时间:
：Facebook、Snapchat、Tumblr等背后的核心技术
Bjorn Freeman-Benson: 我的观点是开发者应该负责他们的应用程序在生产环境上的运维工作，在为其提供另一个论据支持之前，让我先对Carols的论点做出回应。Carols，我想在你说&[可能]开发团队应该负责公司的账务工作，因为软件开发者最擅长处理数字&的时候，是在开玩笑。是的，我并非是说开发者能够做其他所有人的工作。但是，我们并非是说让开发者使用能力范围之外的运维技能。开发者对财务完全是外行。但是配置硬件、部署软件、管理指定应用程序的服务器容量、确定备份日程&&这些运维任务都是在典型的开发者能力范围之内的。
此外，当提到云的时候，你说：&看起来似乎人们期望云中的系统能够自我管理，那是错误的。&是的，很明显云架构不会自我管理。但是我们所说的是与云相关的系统管理工作是由云提供商完成的。因此我说如果我们在将应用程序部署在云中的公司中做IT工作，为什么还需要系统管理员呢？我们应该让开发者来做大部分应用程序管理工作，这样就不需要再建立云团队了。如果一个公司使用的是云平台&&RightScale、Heroku、Stax、Gigaspaces、EngineYard等等&&中的一种，那么大部分的与系统管理相关的工作都是由平台自动完成，而不是由系统管理员人工完成的。
让我给出另一个观点，来说明为什么开发者应该对生产环境中的应用程序负责。谁能够比编写代码的团队更好地找到性能问题的根本原因呢？假设运维团队得到了应用程序的性能出现了问题的警告，可能来自于性能检测工具，或者来自于不可避免的业务人员的电话，他们在其中大发雷霆。典型的运维人员能做什么呢？如果他们极度幸运，那么可能会将产生问题的原因隔离到一些出现问题的架构中。坦率说那种情况十分少见。通常运维人员所使用的各种架构监控工具会显示一切&绿灯&。往往问题都在于应用程序之中。谁能比开发团队更知道在虚拟机中发生了什么呢？大多数运维人员都不是开发者，他们不会读代码，也不能跟踪原因隐藏在程序中的问题。为什么需要运维团队作为中间人来接受警告，然后他只是将问题转交给开发团队？还是让开发人员来接受警告并更快地着手解决问题吧！如果问题在于他们的代码之中，那么他们就应该是修改该问题的不二人选。这样做额外的作用就是让开发者对于他们发布到生产环境中的代码更尽心，因为知道他们需要对结果负责。
&以下内容增加于4月19日
Carlos Armas:
是的，我当时是在开玩笑，:)
我发现使用幽默更便于沟通和理解。我越是阅读你的评论，越是觉得似乎我们的观点并非是像旁观者乍一看所感觉的那样针锋相对。
我同意开发者能够学习并执行很多运维任务，这是肯定的。但是请记住，我还是希望他们能够专注于代码，将该项工作放在第一位，正如我坐在公司所有者的位置而谋其事一样。我在下面陈述你所作出的非常重要的观点时，会再回头来看这个观点。
在此有一个很不固定，并且正在发展的概念：云计算。如果你让我给它下定义，我可能会逃之夭夭。（我可不想作为现代云计算的布道者来吸引眼球）
可以说云计算是个宽泛的概念，它关注的是需要最少或者可能根本不需要运维专业支持的服务(Heroku，以及其它等等）。它还涉及到像Amazon的EC2、Rackspace的RackspaceCloud、Opsource's的OpsourceCloud等服务，其中涉及到大量运维工作，这依赖于所要支持的应用程序的种类。
还有强有力的证据，可以促使Saas提供商专注于非常特定的服务，让类似的团队从提出概念到交付保持持续的服务（这可能正是在New Relic公司中的情况），并极度关注应用程序的交付。
与之相对的例子可能是，公司决定不想花费大量的资金用来改善开发环境，并将其开发架构迁移到EC2。快速提供、迅速转向，或者是其它的什么。你还会想到很多其它的例子。
所以这件事的问题在于，&具体情况具体分析&。
我对你的观点的根本原因进行了分析，在提出我的反对观点之前，让我先强调一下你的一些我观点：
这样做额外的作用是，当开发者将代码发布生产的时候会更尽心，因为他们知道需要对后果负责。
为什么要让运维团队作为中间人来得到警告，然后不管怎样，只是将问题转交给开发团队？
如我所见，如果开发者开始做运维的工作，那么：
开发者会更尽心，因为他们需要对将代码发布生产所带来的后果负责。
这会解决中间人综合症（运维人员）所导致的问题，他们无法修正导致失败的错误
基于实战的经验，我要对上面的观点表示反对：
为什么是那样呢，在很多公司中（显然数量巨大）运维人员被认为（表现为）是妨碍改变的因素，并且向工作流程中添加延迟，以致于几乎不可能保持敏捷并向生产环境发布代码。
为什么运维团队始终是开发团队的阻碍呢？
为什么开发团队要应付严格的公司政策，最终购买云计算服务呢（因为运维团队无法在第一时间提供服务）？
为什么运维团队会因为漏掉了SLA目标而受到惩罚？前提是错误不是与有缺陷的架构或者过程相关，而是与错误的代码相关的。
为什么运维人员无法从云服务的快速、灵活的部署能力中获益呢？难道是70年代的计算实践中的&守护者&精神依然存在吗？
对我来说有些事情已经很清楚了：冲突是切实存在的，但是如果不熟悉信息技术实践的历史，那么就很难梳理出为什么我们因此而受苦的原因。我有一条未经测试并且非常单纯的理论：变更对于运维是有害的，而软件开发就是变更。因此存在最重要的矛盾，这需要聪明地处理。
新从公司所有者的角度来阐述，因为我要花费资金来试图提供管理冲突的过程（是聪明的吗？）。我要使用敏捷的用户故事方式来说明，作为公司所有者，我想要：
软件工程师不负责公司的财务工作（你没看到他们过来吧？:)）
运维工程师主要专注于24/7服务的可用性。
软件工程师主要专注于服务的改善。
在开发和运维之间存在&零壁&规则。
运维工程师是敏捷团队的核心成员。
软件工程师经常会在第三级扩展的待命任务中轮换
这很痛苦，但会有教训
开发和运维团队都会对应用程序的可用性和延迟负责
在此我想坦率地说：丢失的目标，对于任何团队都无益，我不关心谁打破了它。必然的结果是：财务上的问题，会有教训。
运维工程师需要学习服务应用程序层的核心、本质的部分。
现在他们已经可以为设置趋势监控提供帮助，并且能够预测构建场景中的错误。
本质上，我还是想让我的软件开发团队编写代码，构建新的特性来吸引客户的眼球，而不能被其它任何事情来分散精力（包括云计算）。我还是想让运维团队（或者是拥有多名工程师的团队，或者是兼职的远程系统管理员）来调整系统，并能够对构建客户想要的东西的团队做出最快地响应。我还想让运维团队学习应用程序层的关键知识，那样他们就能够不定期地找到针对架构的缺陷（作为唇齿相依的关系，不再对变更抱怨）。
&以下内容增加于4月20日
Bjorn Freeman-Benson: Carlos，多谢你明确了立场。简要地说，我同意大多数你关于开发者如何认识运维人员的说法（变更阻碍者），并且我想要增加对运维人员如何对开发者的认识（一群疯狂的牛仔）。我看到，关于我们的讨论，有很多读者发表了有意思的评论。我已经在线下得到了一些关于影响的反馈（感谢和），我的立场很明确，强烈地反对运维功能。我并非故意如此，并且希望我没有将运维人员描述为完全不必要或者没有能力。我并不认为没有公司需要运维功能，很显然并非如此。
我的立场和观点都集中于应用程序，以及对它们负责的人。毕竟，如果不是为了应用程序的开发和运维，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评论，你可以在此查看：
上面的Twitter工具是免费的、开源的、基于Javascript的库，你可以在此找到：.
查看英文原文：
Author Contacted
架构 & 设计
229 他的粉丝
58 他的粉丝
54 他的粉丝
相关厂商内容
相关赞助商
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
找回密码....
InfoQ账号使用的E-mail
关注你最喜爱的话题和作者
快速浏览网站内你所感兴趣话题的精选内容。
内容自由定制
选择想要阅读的主题和喜爱的作者定制自己的新闻源。
设置通知机制以获取内容更新对您而言是否重要
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。在 SegmentFault，解决技术问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
一线的工程师、著名开源项目的作者们，都在这里：
获取验证码
已有账号？
问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
07-15更新:
撸主五月份换工作了, 去了某狐, 后端方向. 战战兢兢的适应期, 现在可以欢快的写代码了.
04-08更新：
像下面很多回复所言，如果要换行业，在行业观念/年龄/待遇方面确实存在诸多矛盾。
现在我想引申出一个更通用的问题： “当你所处的行业正在日渐式微，作为一个走技术路线的码农应该如何改变以应对呢? 无论是现在的互联网或者其他的行业，过十年甚至几十年后似乎都会面对这个问题”。
做为一个技术手艺人，想听听大家的看法。
非常感谢留言的各位，你们的建议对我都很有帮助，尤其是泼冷水的建议正是我需要的。ps这里讨论的气氛非常好：）
04-02原帖:
先介绍下自己的现状：
传统行业的程序员，工作5年。以前主要做分析仪器/。最近几年的工作主要就是嵌入式Linux+C。
我为什么想要离开自己熟悉的行业
这个念头并非突发奇想，因为我觉得我是一个很GEEK的人，喜欢关注流行，很潮的技术。比如动态语言、Ruby、Python、nginx、并发、大数据。但这些东西离我现在的工作内容非常远，每天和寄存器，底层驱动，还有跟芯片厂商封装了无数层的SDK打交道。
传统软件行业技术更新的很慢，并且在工作中无法接触到我喜欢的东西。“被过时”的概率比较大。所以，我打算换行业。
编程语言：C/C++，Bash Shell；
GNU工具：GCC/Make/GDB, Vim；
操作系统：Debian，AIX Unix，日常使用Fedora；
英语水平：无障碍阅读英文手册，无障碍使用Stackoverflow；
C这几年写的很多，C++最近写的少，不过重新熟悉问题不大；Shell脚本能自己看自己改，算不上突出。
Linux服务器配置马马虎虎，大多问题能自己google解决。日常使用Fedora，Vim。
Github有，就在上面写写验证代码，在这里还是不要拿出来现眼了。
数据库仅仅在几年前刚工作的时候接触了一下oracle/db2，之后从事嵌入式行业的几年里就没有再摸过。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
我对软件硬件都感兴趣，专业是电子信息工程，硬件方面的，但毕业后从事软件开发方面的工作，已经快10年了。换过几次行业，从Flash教育软件到Web前端，再到Web后端（Ruby）+前端。（可能有人觉得不算换行业，呵呵）
我想说的是： 互联网开发比嵌入式开发简单多了，因为更有趣。
兴趣是最好的老师，如果你想换行业，那么可以尝试在业余时间玩起来。
如果发现这是一件愉快的事情，那很好，继续 玩&积累;
如果没有觉得web开发的过程中有什么成就感，那么可能是不适合这个行业。
优秀的互联网开发者有几种气质。
一是“天下武功，唯快不破”的精神。有别于硬件、传统软件，互联网开发需要快速从用户中获取反馈、提取数据，快速迭代去优化产品。所以他们会特别珍惜自己的时间，想法设法提高自己的工作效率。并懂得何时应该不做什么事情，怎样少写代码。
二是内心永远充满了好奇心和学习的激情。当一种新技术出现后，他觉得：”哇，真不错！能做的事情又更多了！“， 而不是：”又要学新的东西了，真郁闷“。
但这些和互联网行业背景并没有太大关系。你可能会发现嵌入式开发领域也需要这样的气质。
不管你以前是开书店的，还是做嵌入式开发的，只要愿意去了解，去学习，都是可以跨界n个行业的。可怕的是被原先的行业背景给束缚住了，停留在自己舒适区里，用僵化的眼光去衡量一切。
要入行真的很容易，有一些作品就说明你已经入门了。
如果要换行业的话，可能需要经历短暂的收入降低。我自己换过两次行业，一次是降薪，一次丧失了晋升机会。但每次都让我很开心，因为能力提升了。（我换行业的原因是想让自己能做更多的东西，想让自己的idea能成为现实）
总之，只有舍得，才能得到更多。可以舍弃的越多，内心就越自由。昨天的辉煌，不要成为今天的枷锁，呵呵。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
楼主想要转换行业是一个需要大毅力才能完成的事情，虽然嵌入式转互联网看上去还靠点边，但作为一个雇主来看，我还更倾向于招一个完全不搭边的人。因为你从事的行业，对不起我说话很直接，是一个夕阳行业。
我大学是学电子信息工程的，我的大部分同学现在都在做嵌入式，你们觉得现在软硬结合很火，那传统嵌入式从业者是不是就能走出来了呢？完全不是这样，从我跟他们的交流中发现，他们对互联网的理解大概跟你老家里面的亲戚朋友差不多。什么意思，他们没有成为这股浪潮的缔造者，而成为了旁观者。
当然也有如楼主这样的醒悟者已经认识到自己再不做改变，就会过时了，我觉得如果我是雇主这才是我最看中的一点。
不被时局所迷惑，拥抱变化。我想，虽然你还没有进入这一行业，但你已经被眼前的形势给上了一课了。
我个人给你的职业建议
如果你想做纯互联网的工作，我估计应聘的成功率跟无经验的毕业生差不多。因为你已经从业5年了，年龄应该不小了，人家给你工资的时候肯定不能按应届生给，但是你的水平摆在那里，所以会让用人单位比较为难。我建议你先发动人脉，去你朋友或者熟人的公司厚着脸皮先去锻炼下吧，虽然都是写c++，但是互联网里要写的东西完全是两码事。
证明你自己的价值，当你能够证明这一点的时候你可以出去碰碰运气了。公司不是福利院，人家没有义务为了你实现个人理想而买单，所以你必须证明自己的价值。
软硬结合确实是个好方向，我也建议你往这方面走，完全放下你以前做过的事情，从成本上考虑也不划算，你已经落后了，要是再不借力很难追上别人，利用你自身具备的优势。但是这个行业现在才刚开始，里面都是一堆初创公司，风险比较大，所以自己考虑吧。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
我觉得说先辞职，互联网机会很多，工作很好找这种话有些不负责任。单身美女也很多，为什么程序员还有这么多单身？
正好前两天面试了一名传统行业想转型到互联网公司的程序员。站在公司角度有很多考虑的因素，就算面试了很不错的人，有时候也因为没办法提供合适的岗位要拒绝掉，很无奈。直接贴邮件内容：
A: 您好，面试结果是？ 如果没通过能否告知原因。 谢谢！
B:你好，很抱歉一直没有回复你，让你久等了，说实话，这不符合我们的办事风格，我们之所以没有给你回，是我们在见完你之后从个性和能力上来说，我们觉得你很不错，但是有两个问题，第一，没有互联网公司经验，第二，JAVA背景并且看上去并非想从技术角度深挖的人。
我之前让你和我们HR、老板继续谈的原因是我觉得我们有一块新的业务可以交给你，后来我们合计了一下，大家的结论是纯JAVA背景的人来负责这个项目可能不是很合适，毕竟你自己还需要一个适应和学习的过程，在节奏上会跟不上整体的需求，短期内也无法给你配备更多的人。
后面我们觉得你可能适合做PM的角色，我们目前分组工作确实需要一个PM的角色，同样基于你过去的经历，我们做了保守的评估，可能你暂时不太适合做PM的角色。
总体而言，我们觉得你很优秀，但是我们暂时无法提供你合适的职位。
A:您好，很抱歉，再次打搅您了。首先感谢您的回复，很真诚，很实在，没有那么多的官方说辞。谢谢。还是想再沟通下，想"浑水摸鱼"下。目前我们公司是否招收"应届生"作为培养对象，如果可以的话，是否可以把我当成应届生进行处理。以后的发展可以视能力而定。谢谢！
B:抱歉，我觉得这样对你不太公平，我们更希望人能尽其用。杭州的互联网圈子不小，你应该能找到更合适的团队和职位。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
基础这么扎实的人，学起什么来，都会比较快。
建议目前多看看业内的资讯，然后，找一个自已最喜欢的方向做接入口。
熟练以后，再找一个您认为更具“发展潜力”的方向来深入学习。
基础决定上层建筑，相信你会有一个辉煌的未来。
像我就是半路出家，自身学通信工程的，完全捧着各种杂书，底子奇差无比，学什么都累的要屎。
再就是楼上胸低说的，英语很重要，非常重要。口语可以烂，但必须要突破阅读障碍。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
技能离产品比较远，建议先熟悉产品，web、app、游戏之类的，没事都看看，想想他们怎么实现的。
关注下行业新闻，看看某个公司的主营业务是什么，为什么做的如此好，他们的技术人员在技术方面都做了哪些努力和实践。
然后选一个或几个方向深入学习、python、go、node、java之类的都行。技术本身并不是局限，想做什么才是。比如web或app，就肯定得选个支持http的吧，也许说的不深入，但就是这个意思。c和bash做运维的时候可以用，问题是并不知道你是否打算做运维或数据库，所以还是回到前面的话题，先想想自己喜欢做什么。再去学语言。
对合格的技术人员来讲，无需强调英文能力，可以几乎肯定的说，英文阅读有障碍的，无法成为合格的程序员。
你有令人非常羡慕的技术积累，比我这种半吊子出家，直接啃谭浩强的垃圾书，拿着PHP上手，没什么经验就开始玩网站的人基础深太多了，我觉得未来你会做的很棒。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
我是一个入行做外包项目，后来直接跳槽国外公司，定居国外继续做软件的程序猿。
我很奇怪的发现楼上各位都有一个共识，嵌入式开发行业是个过时的方向，再这么做下去会"后果严重"。这个我严重不同意。
也许是整体的软件行业土壤不一样造成的。
对于码农，至少我这里相同经验年限的嵌入式码农的薪水，是比前端web系码农薪水明显搞1个档次的。
稳定，大型的系统，开发维护使用周期都是十几年为一单位的，所以对行业方向的担心完全是多余的，无论什么方向能做到"精通"才是关键。
楼主真要跳出嵌入式，也不一定去搞web系，那些专注金融系统，银行系统，通讯交换机系统等等的公司，用C，甚至COBOL都很多，这些能跟楼主技术积累比较合适。甚至发挥下英语能力，搞欧美系，无论技术，还是薪水都有很大的发展空间。
PS:由于稀缺，我这里精通"更老旧"的COBOL的人，基本都能拿到码农一级的顶薪。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
我觉得互联网行业要比你从事的行业简单。而且互联网行业也有不同的领域！如果想从事web相关的，那Java和php肯定是目前的主流。如果是游戏，c++或者c还有一些脚本语言lua。但是我感觉技术是相通的。最主要的还是你迈出第一步-------------辞职，开始投简历！！！
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
你的经历转互联网轻而易举。有C/CPP做基础去学脚本语言很轻松。PHP/Python/Ruby选一个学一学，了解一下PostgreSQL/MYSQL就可以上手了。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
题主足以秒杀很多互联网程序员了，写服务器端程序毫无障碍，做更底层的工作也没问题的。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
我倒是同意楼上，考虑下低功耗设备上做web服务器？听说HP有搞，可能是个趋势。干5年再换行业感觉略亏。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
你是高手啊，会硬件，会系统底层。我从前端走向底层，路途遥远啊
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
屌丝终有逆袭日。我是在医疗检测行业，现在还是搞web和app开发，祝你好运！
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
祝贺楼主找到满意的工作。我作为一个有10年经验的老码农，前面3-4年主要在搞windows和linux的网络驱动，中间3-4年主要在搞嵌入式linux的路由器，最近3-4年主要在搞Android开发和PHP/MySQL系统。主要行业还是在无线Wifi路由器方向。现在30多岁的年龄，面临再次择业的困惑。希望楼主和各位网友能帮我节节惑。感激不尽啊
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
楼主成功进入互联网行业了吗？我和你经历相似，最近也想转到互联网行业，不知道该准备些什么。
同步到新浪微博
分享到微博？
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：}