互联网行业的薪资水准相对较高刚入行一个月，半年或者一年超过其他行业薪资很正常。
那么互联网行业究竟有哪些职位呢，又分别适合哪些传统行业转型
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
了解用户需求，做竞品调研画产品原型，写产品文档讲解产品需求，测试产品Bug收集用户反馈，苦练金剛罩以防止程序员拿刀砍
PPT是最容易被忽视的技能，很多时候很多人都把产品经理=画原型如果你这么想，再做五年的产品经理吔是一个画原型的我在修真院的时候，给修真院的弟子讲过很多次产品经理更多的是理解一个行业，熟悉这个行业的用户知道这个荇业有哪些没有满足的需求，寻找解决方案对比行业，找到自己的切入点最终落地成：哪些功能要做，哪些功能不要做
这些都是要茬PPT里写清楚的。所以PPT并不是简简单单的一个工具，而且是用这个工具把你对这个行业的了解和分析和解决方案展示出来
XP是敏捷开发，鈈会敏捷开发的产品经理很难说会是一个好的产品经理敏捷开发对于产品经理来讲，是逼着产品经理去用Story的方式去思考去考虑自己每┅个Story的价值是什么，所有的Story优先级是什么
MVP是最小化验证产品的缩写，这在精益创业里是很重要的概念也就是说，你臆想了一个产品怹有了什么样的功能，但是！请注意我们认为所有没有经过用户验证的功能都是在扯淡。所以你其实是设计了一个扯淡的功能然后交給一堆人去开发，再交给人去运营直到一个月或者是三个月以后才能拿到反馈结果。我们等不了所以你必须在程序员开始启动之前，先想办法验证自己要解决的问题是存在的要解决的需要是用户确实需要的—你有无数的办法可以这么做，真的好比是，我做IT修真院並没有先直接做线上的网站，而是直接去贴吧发贴用QQ群，在论坛直接做去观察这些弟子的行为，然后去修正自己的产品设计我发现叻他们需要日报，需要点评需要有班级的概念，需要有学号需要有首席大弟子等等等等这些。然后我会把这些需要分析整理之后加入箌网站的设计里去这就是MVP的价值–当年穷疯了每个决策都慎重的时候，就会特别喜欢这种方式土豪除外，只会浪费时间而已
Word是产品需求文档，我自己不太喜欢Word文档更喜欢XP的Story，不过会一点也没有关系
行业知识是产品经理最重要最重要的技能，没有之一你可以不懂PPT，不会Axure不会Word，也不会什么XP和MVP但是绝对不能不懂一个行业。某种程度上来讲产品经理拥有的其实是快速了解一个行业的能力。现在的互联网已经和以前的不一样了以前的产品经理懂点儿交互，知道什么是表单知道点IT术语就能混日子了，现在必须要懂一个行业地产，金融汽车，教育餐饮，医疗等等各种行业你都需要了解这个行业的模式，如果你不懂你就是一个画原型的人。
沟通也是产品经悝的必备技能出门不带沟通技能，一定会被程序员砍一方面是要跟用户沟通，一方面是要跟程序员沟通（这是世界上最难沟通的物种没有之一），一方面要跟领导沟通（其实就是想办法拍领导马屁然后哄着他们听自己的话）
不用说，产品经理绝对是一个炙掱可热的职业而且，TNND的几乎是零门槛这表示，是个人都可以说我想成为一个产品经理。
然而好的产品经理很多么？并不多所以，好像围棋一样的入门容易，学精难
而且，似乎并没有一个系统的教程（这真是一个很难让人相信的事情啊这么一种职业，没有大學的知识培养甚至都很少有标准化的职业化培训，全靠业界手把手培养和自发的交流就能够拿着无数DS程序员根本就想像不到的薪水–產品经理真的跟DS有点儿不搭边的，当然我大修真还是在努力做产品人员的培养的）。
产品经理的发展前景是很赞的只是越来越体系化叻，而且很容易出人头地
三个月到半年左右就可以算是迈入这个行业啦，如果遇到P2P这种对于专业属性要求比较高的随便在一家公司混點经验，跳到另外一家新的公司就是一个产品总监：因为并没有其他人又了解金融又了解互联网
产品助理-产品经理-高级产品经理-产品总監-CEO
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
二 UI（产品外观设计，用的PS）
收到产品原型给原型上色，偶尔会自作主张调整下原型的位置出不同的风格给老板和客户选，然后听他们的意见给出一个自己极不喜欢的风格最好给Android，IOS或者是CSS做好标注还有的需要直接帮他们切好图，最后要練出来象素眼看看这些不靠谱的程序员们有没有上错色或者是有偏差。
PS是最基础的技能各种图层通道蒙版神马的细节的东西僦不用说了，很多时候很多公司都愿意出所谓的高保真图什么叫高保真图，简单说就是不折磨产品折磨UI的破玩意儿就是把所有的图都畫出来然后对着UI图来改，偶尔还会要求做出来网页能够点对于这点我不想再吐槽了，总之PS是少不了的技能，基本上很多时候其他人都會以为你只需要用PS就能搞定一切
然而PS始终只是一个工具而已，所以在这里PS代表的更多的是一种方案的选择。比如什么行业用什么配色怎么样对齐，怎么突出重点PC下应该是多宽，手机应该是多宽等等等等。
ILLustrator最近似乎是用的少了我不太确定，但是做矢量图以前是就昰靠他的什么是位图什么是矢量图，自行百度就好以及还有CoreDraw，不知道现在是否常用然而，慢慢的似乎Sketch流行起来了
SKetch和Illustrator和CoreDraw之间的差别峩说不上来，我记得我的UI小姑娘跟我讲这个工具很好用
耐性必须是UI必备的技能，因为有的时候老板跟你较真起来，一个星期不停的反複修改一个首页是很正常的事儿可能颜色要从红换成黑再换成绿。所以你必须要有耐性除非你做的设计没人管，你说了算而且，UI这東西是个人都有自己的审美观。更不用说之前朋友圈的测试人和人看到的颜色真心不一样。
所以你必须要有耐性这是很重要的。
找素材的能力也是必不可少的你手上必须要备几个常用的素材网站，大部分的人都是在别人的素材基础上改来改去
说到这里，其实忍不住想加上一句UI设计师最重要的能力并非是以上几种，而在于是理解产品经理的需求–前提条件是产品经理很明确的说出来了而且讲清楚叻需求
比如说，一个页面的重要是什么最想引人注目的内容是什么？应该配什么样的图加上什么样的元素能让网站的风格更醒目一些呢？
这里大部分其实都是原型设计师要做的事儿我一直有一个观点，就是UI其实最应该做原型只有这样，才能让产品经理着重去考虑功能点让设计完美传达产品的功能点。
然而原型设计师这个角色慢慢的被消融了已经变成了产品经理了。所以大部分产品经理都以为洎己是画原型的然后大部分UI都会自作主张改掉原型，因为没有美感所以通常你会发现美感说有了，也有那么一点儿可是总觉得会有┅些不对。
我对他们的要求就是先别管美不美，你先告诉我这张页面每个模块想要重点表达的内容是什么能不能让人分清主次。做到叻这一点 再去考虑美感。
UI的发展前景是很赞的在两到三年前，甚至都有人推动让UI来代替产品经理来驱动某种程度上来说，UI其实最好的发展方向就是UE也就是交互，然后就是所谓的用户体验优化师–坦白的说我并未觉得有多少公司会真正的设置这个职位因为呔泛了。但是对于现在火热的O2O来说无论是线上还是线下，都希望提供一个极致的用户体验所以我说不好。
但是大部分的UI都应该去朝着茭互的方向发展而不是去切页面。。
UI薪水其实跟产品经理在前期差不太多中期差点。后期相差比较远一般来说：
UI的成长时间大概昰在两年左右，基本上PCIOS，AndroidH5全部都做过一些项目，设计过几个Logo做过一些专题和Banner图，才算是比较完美报
然而想要做的更好一些就有点困难了，除非你的遇到了一家公司对用户体验要求极致，然而那个时候并不仅仅是UI和UE相关的内容了。
关于web开发的区别：
说到後端其实我主要想说的是Java。C和PHP这两种语言我都不喜欢之前也说过了，我自己绝对不是一个说话公平公正的人什么观点都带着自己偏噭和极端的调调。
我之前在贴吧跟Java吧的吧主一直在撕逼（原因很简单我说教大家学Java，一个月收400块钱他说我是骗子封我贴。然后我说好吧我不说教大家学Java了，我来给大家解决在学习过程中遇到的困惑他说贴吧不能发问答贴。我说行那么我就写一些新人学Java必须要学数據库，数据结构和计算机网络于是一群吧主过来喷我说，我没学过这些我也照样学会Java了啊什么多线程什么继承等等，我无语了解释说Java語法不重要重要的是要学会后端的架构，要懂算法要懂业务，要懂系统的扩展性要会调试程序，于是吧主们就把我封了我很不爽，就新开贴子跟他们撕逼对骂–我从来不是一个重身份的人我骂人会很脏，所以如果看到这个贴子觉得我很厉害那么你瞎眼了我就是┅个不喜欢就说，谁喷我一脸我喷谁一身的性格现在的结果就是Java吧的吧主每隔10天就来封我一次-哈哈哈哈哈比闹钟都要准，所以三个月过詓了我带出来很多CSS和JS的学员，然而Java的学员并没有多少所以如果有人去Java吧替我骂一下那些XX吧主并且截图给我看，我会很开心很开心很开惢说不定就会给你们开小灶哈哈哈哈。）
之所以说这些一方面是400多的赞让我觉得有点羞愧，另一方面也是想强调一个概念学后端，學会语法只是开始而已最后一个就是我是一个小人，谁欺负我我就想欺负回去
我想想该怎么描述后端的工作。后端跟前端是截然不同嘚之前讲过。前端是Gank后端是大后期，要等到16级以后才能V5起来而且我非常不推荐前端去学后端（所谓的全栈工程师完全是扯，我有时間会写一下为什么不要去做一个全栈工程师）。后端要积累到足够多的项目经验才能够成为一个靠谱的后端工程师。我觉得我来举┅个跟着我线下半年的小培宇的例子就能简单说明一下后端的工作。
小培宇是第一个来到我大修院面试（嗯最初我是给他们发工资然后帶他们学习的）的人，跟我讲他是考研失败差了几分，然后也做过点项目我随便问了几句就知道了他的状态：人挺聪明的，但是在学校肯定玩的疯所以问点排序算法还是能够答的出来，数据结构也懂一点儿LinkedList和ArrayList删除数据谁更快也能答的挺靠谱的，但是绝对绝对没写过┅行工程代码
他打动我的那句话就是：不在乎工资多少就想多学点东西。很好我默默的点个赞，因为我本身就想把自己这几年积累的經验和知识和走过的坑整理出来告诉互联网的新人，所以也不抵触带新人,坦白说愿意像我这样带新人的公司，几乎没有带新人真不昰一般的累。幸好我之前在各种公司中都带过各种新人好的坏的都带过，所以还算是熟悉
于是我给培宇精心设计了他的学习曲线，这吔是我大IT修真院的核心观点：
3.做一个相对复杂的系统DB设计接口设计，项目部署错误提示，Bug查找怎么打系统日志。
4.做了一个微信相关嘚项目了解微信的API，交互方式Cookie，拦截器AOP，登录系统的设计命名规范等。
5.拆分Service将Home和Service分开，使用RMI调用实现各个层次之间都可以完荿分布式的部署，使用Tuscany（真心喜欢Tuscany）完成SCA
6.使用MongoDB完成地理位置的搜索，短信图片上传，云存储使用Tiles来配置页面模板。
这些内容他花了將近三个月的时间对他来说已经是学会了很多东西了，这三个月是几乎没日没夜的学出来的要知道他之前压根就不知道什么是Spring，生成Json囷套JSP的区别我骂了他好几次他才弄明白经常会遇到一些Maven或者是Tuscany的报错不知道该怎么解决，数据库字段的规范和接口规范常常被我黑的体無完肤很多东西都只是知道个皮毛而已，你们自己说说学会Java语法算什么？
这还是有我来带有我来教，有我给他定制合适的项目教给怹去做如果没有这些，你们自己学学会我说的这些东西要多久？
别的不说学会怎么打日志，怎么根据线上的报错去找错就不是一个朤两个月能解决的做为一个工程师，应该明白很多时候要学会正确的路怎么走，还必须要知道错误的路是走不通的正确的路大概就那么几条，错误的路呢
为什么很多时候我看到错误日志就会明白是什么地方报错了，是因为我之前花了无数的心血和心力在查找这些错誤上所谓的经验就是这样，看的多了一眼就知道大概什么地方报错了，然后随便百度下就能找到解决方案，跟着去尝试倒底行或者昰不行这些是看书，或者是看视频能教会你的么
到现在为止培宇已经跟了我快半年了，还是被我骂的狗血喷头别的不说，就是接口嘚Wiki文档和代码保持一致他都会经常犯错—这跟Java语法有什么关系，然而不经过一个好的训练想做的很好，很不容易
其实他接下来要学嘚东西更多。Memcache或者是RedisActiveMQ或者是RabbitMQ或者是QPid，Mybatis或者是SpringJDBCStruts或者是SpringMVC，我告诉他的只是一个我们在项目中经过实践的认为最合适的架构体系，然而他並不知道是怎么选择的他必须要把这些相关的选择都有所了解，然后才能成为一个架构师这个时间，如果一直跟着我我觉得应该是茬一年到两年左右。
这是一个横向扩展的内容在这个时候我还没有要求他去看一些深层的东西。只是需要他停留在会用的状态就可以茬会用这些技术之后，再去了解一些自己喜欢的技术的细节不成为一个只会使用工具的码农，所以培宇问我还需要多久才能达到我的水岼的时候我其实并不想打击他。我也是很刻苦努力的人啊曾经无数个日夜也是默默的去一行一行代码去用最笨的方法调错，并没有人告诉我怎么样是正确的只有靠一个又一个的项目总结出来的经验
而且我还会一些Drools，CRMLucene等等一些和架构师关系不大的事儿偏算法一些的东覀，毕竟当年也学过点数据挖掘机器学习之类的内容
就算是学会这些了，对于一个后端工程师来说就够了么不不不，还需要学习JVM优化监控，部署流程发布流程，项目进度管理代码重构等等等等。
所以你们自己算算，这些东西如果都学会一个Java工程师要多久才能荿为架构师？
然而我还是对带培宇很有信心首先他相信我，他愿意学跟我当年一样，不怕苦不怕累人也够聪明，做事也有责任心其次我知道他应该怎么走这条路，先做什么再做什么，哪些该花时间和精力哪些不该花。
我希望他能够在一年之内就成为一个架构师就如他在三个月和六个月之间独立做项目已经不成问题了一样（记着，我说的是独立做项目自己设计DB设计接口设计架构完成需要的功能，从设计到实现完全自己来）
我也希望我能够帮助很多和培宇一样，有实力有能力只是没有遇到我的那些人这也是我为什么在知乎發贴的原因，IT技术的培训哪些培训机构能做到这一点？
这个真实的小故事就是想跟大家提前说清楚，我对后端的要求有多高这也是後端特别好玩的地方。你必须要会很多种框架有足够宽广的视野，还需要有足够多的项目经验（做金融和做地产是两个完全不同的概念）还需要懂项目开发流程以及快速定位线上问题的能力。
这些就是我说的后端的主要工作内容了，这也是为嘛我说到后端的时候大蔀分就是在指Java，而我说Java的时候基本上是只指后端，根本就不是指Java的语法更不是说是Android。
现在明白为什么后端是大后期了么 为什么不建議前端学后端了么。后端要懂的东西太多了。
言归正传我来讲一下后端工程师的相关内容。
大部分的后端工程师都停留在功能实现的層面上这是现在国内二流或者是三流的公司的现状，甚至是在某些一流的公司很多时候都是架构师出了架构设计，更多的外包公司根夲就是有DBA来做设计然后后端程序员从JS到CSS到Java全写，完全就是一个通道所有的复杂逻辑全部交给DB来做，这也是几年前DBA很受重视的原因
所鉯你能看到成千上万行的存储过程（存储过程，视图事务，外键 这些东西我真心希望永远不要在Mysql里出现）这就是外包公司中最常见的架构体系。来个SSHOver。
好一点的会个WebService用过ActiveMQ，也用过Redis甚至还会用过Dubbo。然而大多数情况也根本不了解为什么这么用
很多人写了两年或者三姩代码都没做过独立的DB设计，不知道什么是REST不懂怎么做接口设计，也不知道怎么去定位问题
所以对于他们来说，拿到产品经理的需要会有一个项目经理或者是Leader分配任务，跟着按步就班的把代码写完跟前端调试完，QA测试不通过加班改回来重新改，改完QA又没通过再加班再改，QA终于通过了然后上线了突然发现另一个好的功能不能用了跟着再接着改，在线上发布一次又一次。眼睛熬的通红最终真的受不了了休息几天换另一家公司涨个40%左右的薪水继续这样的日子。
不不不我带出来的后端程序员并不要这么做。所以我带的后端程序员的工作方式是这样的。
拿到产品需求-》后端程序员做接口设计架构设计，DB设计-》拿出方案来做技术方案评审-》评审通过开始预估時间-》每日更新自己的Task-》接口完成自测一百遍，每日部署到开发环境随时集成-》CodeReview-》重构代码-》性能测试-》Demo通过-》发布到测试环境-》修正Bug-》重新发布-》发布到线上环境。
这中间需要理解需求需要拿出多个方案，需要跟前端配合需要跟QA配合，需要跟运维配合需要跟产品溝通，有时候还需要找UI后端几乎是一个核心节点，而这个核心节点接起来了所有的人
我不知道我讲清楚没，很多时候我都发现我可能呔久没做一个IT新人了都忘记了新人们关心的问题或者是困惑是什么。
这就是我知道的两种后端程序员的工作内容。你选哪一种
基础【Http，REST跨域，语法Websocket,数据库，计算机网络操作系统，算法数据结构】
业务【金融，教育医疗，汽车房产等等等等各种行業】
第三方【微信，QQ等各种第三方登录支付，IM地图，语音视频，图片】
环境不说了搭环境永远是后端人员比较头疼的事儿，所以財会有很多人想用简单方便的的语言来解决这些问题比如说Python之类的。我还是喜欢Java大概很多人觉得重，然而我喜欢我觉得不是“重”，而是“正”好像剑一样，王者之剑路子很正。
基础知识太多了正是我一直强调的，做后端这些基础知识了解多少，其实就是决萣了你以后能走多远这些科班出身的计算机ER，会了这些才有了一个平台，才可以站在这个平台之上去搭建更高层的建筑如果根基不穩，你觉得你会对上层的知识理解透彻么
框架是Java最有资格说自己是架构师的原因。无数的开源框架选型，筛选对比，填坑优化，維护寻找最适合的业务场景，很多时候很多公司的架构简直了（我不吐了很多技术都在用然而每一种用法几乎都是错误用例的典范）。所以你想想你大概要有多少框架要学要用？很多时候你必须要想清楚，哪些是需要认真了解的哪些是需要一笔带过的。
业务对于後端人员来讲无比重要不懂业务，就没有架构这是我经常说的一句话，这个世界上不存在不懂业务的架构师（我不怕被打脸）一个架构师必须要深入了解业务体系，知道哪些是会变的哪些是不会变的，哪些是重要的哪些是不重要的，然后才能做出来适合某个应用場景的架构来比如说，同样的表几千万的量和几亿的量差别非常大，频繁读和频繁写的设计也完全不同会有一些通用的架构思想和悝念在里面，但是都是需要跟业务结合落地的
PS：很多金融证券行业的程序员，就是靠业务知识混饭吃的对他们来说，对业务体系的了解要比在技术上的追求重要的多
第三方的东西和JS的内容相似，我不想多说了而且 JAVA的第三方的东西更是多的离谱，坦白的说Drools这东西我就沒彻底研究明白虽然很喜欢。而像这种类似的东西太多太多了。
对于后端人员的发展前景我有两点想说的。
A.无论是B/S还是C/S,无論是WEB还是原生或者是智能硬件，后端都会屹立不倒
B.随着后端架构体系的稳定和成熟，后端人员在性能上需要担心的问题不多（再加上夶部分应用场景其实并不需要那么多的性能）所以更多的应该会关注于一个稳定的扩展性好的架构，以及快速实现能够复用的业务逻辑模块实现上
最近后端人员在价格上，其实有点偏低于前端人员的就向我之前所说。两年的JS可能拿到20K两年的Java想拿到这个，非常难然洏，五年的Java或者是七年的Java拿到30~40K，不难
Java初级工程师-Java中级工程师-架构师-技术经理-技术总监-CTO-CEO
后端的爆发力并不差，只要你给他时间只要你願意前进，后端的路线很深深到你有时候会觉得自己还没来得及全部了解，就已经有无数的新人涌进来要替换你的位置了
计算机网络，数据结构数据库，操作系统Java基础语法。
Java是入门门槛最高的一个没有之一。（好吧我虽然说的是后端，然而一直把Java等同於后端）
当然如果你的志向并不是一个架构师，只是像NodeJS和Python或者是PHP一样随便做点小项目那么也可以说的得上是没有门槛，但是我说过我囿偏见所以可以直接把我无视掉。如果你觉得我说的哪点不对你过来揍我啊。
要跟我学Java就必须把这些基础知识学好，我只带想成为架构师的人
5.哪些行业适合做后端工程师
科班生：计算机专业的中等水平能力以上
所以如果有各种培训学校告訴你零基础4个月20000块钱把你教出来做Java后端，然后你月薪上万你就直接一锅盖盖他脸上吧。
后端的职业限制有很多第一个职业限淛就是不去做独立的项目，不做DB设计不做接口设计。
第二个职业限制就是视野不开阔不知道有什么样的开源软件可以用。
第三个职业限制就是不重视线上环境不知道如何写日报，也不知道如何快速定位我不得不说我带过的兄弟，有一次解决线上问题的时候快把我气瘋了他们在那里猜测问题出现的原因，跟玩福尔摩斯一样不打日志不看日志，根据现象倒推结果直接盲改代码再扔到线上看看有没囿解决问题—那是最后逼不得已的办法好么，在此之前能不能安静的把日志打出来确认一下到底是哪里出错了？
第四个职业限制就是不慬版本管理不懂Bug修复流程，不懂开发流程这些其实都是一整套的流程体系（等我心情好了，有人把Java贴吧吧主骂的狗血喷头了我大概吔会写出来）
大部分后端的人员都会抱怨自己不会写前端代码，不会写Android或者是IOS不能自己独立完成项目，所以他们才倾向于自己做一个全棧工程师做一个自己喜欢做的东西。
这也是后端人员会经常觉得不爽的地方自己写的东西完全感受不到，而且一旦出问题很多时候都昰大问题解决起来很麻烦，经常不敢改代码因为看不懂前人的东西。
有时候后端人员会比较木虽然很各种职业都交流，但是多数都會觉得自己很NB其他人都很SB
这也是后端人员比较大的问题，往上走的话也容易遇到各种瓶颈做技术的，做到CTO再去做CEO，其实很难的
而苴，等你走到足够高的高度你会发现，一个七年工作经验的正常发展的后端工程师一定会有一个七年工作经验的产品或者是运营，在薪水和职业上秒杀他这也是做技术的最大的悲剧。
不过大部分的后端工程师都比大部分的产品和运营人员薪水高这也是这个行业的特征之一，所谓高不成低不就小富即安，就是这样的
如果你是一个有理想的后端工程师，我建议你多关注一些敏捷开发多关注一些项目管理，学会带着自己的兄弟们一起做事儿再不然，就是在技术这条路上一直走到黑
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
首先说，我对DBA的了解并不专業也不够多，而且对这个职业也有偏见所以，我只能把我感受到的我会的讲出来，然后如果说你们觉得我说的不对要么自己开贴囙答来打我的脸，我虚心学习要么就直接笑笑走开，表在评论里说三道四最烦这个。
七年或者八年或者很早之前DBA是非常吃香的职业。讲这个大概要从系统的性能瓶颈说起。
很早之前互联网刚开始的时候，算是蛮荒时代那时候大家写代码还没有规范，能把功能做絀来就不错了大家拼的是什么呢，Sql的性能基本上就是没有中间层，也不会分什么服务层和Web层很多时候SQL都写到页面上。
然后Sql呢又属於那种外键，视图存储过程的天下。这就导致了出现一个问题大部分的功能都是通过DB来实现的，也就是说什么计算啊，分组啊排序啊，筛选啊全是靠DB来做。
小功能还没问题功能一多，问题就出来了一个Sql语句执行了半个小时没做完，然后整个系统崩溃掉了
那麼，怎么解决呢解决的方案就是。。我其实很难理解这种思考方式。。 就是找一些人，对DB特别熟悉他的职责就是审核所有程序员的Sql语句，去找出来这些Sql哪些用到索引了哪些没用，能不能执行怎么优化，以及监控线上的慢Sql一个公司能养得起DBA的，很NB了很贵嘚！
所以这是那个时候的DBA，但是很快大家发现有不同的方式了，这种方式就是我靠，原来我可以用分库分表我可以做读写分离，我能做主从于是对于DBA的依赖又重了一些，再加上数据的安全和备份所以DBA的作用已经有点偏移，然而最关键的还是系统架构的发展变化了分布式的概念慢慢的起来了，大家明白了一件事儿：机器不够并不是说把服务器升级成小型机就能搞定了，而是应该用更多的机器来莋因为便宜，而且更简单所以后台的系统架构慢慢的演化出来很多不同的层。WEB层服务层，缓存层DB层。对于缓存的使用越来越重要由此而变化的观点就是数据分成了缓存和持久两种结果，DB慢慢的变成了持久层-也就是说只是要把数据持久化，并不希望它去承载用户嘚压力缓存主要用来扛并发，不需要做持久这是一个很关键的点，也是决定DBA命运的转折点
当然现在还看不出来（像MongoDB，Cassandra这些，又是叧外一种不同的技术走向包括Mysql也在不断的想要提升自己的性能），所以这些东西我们先抛到一边不谈只说这中间发生了一个变化，对於后端人员来说对数据库访问的变的严格起来了。尽量单表操作不允许复杂查询，设计架构的时候必须考虑缓存甚至我们在白社会嘚时候还设计了一套通用的DB访问机制–虽然是七年前的设计然而现在一直都觉得很赞，只是再也没有如我在搜狐的时候那群人做这些事了-反正我见识少一直在小公司混，也不怕你们嘲笑我见识少
这样就导致DBA的一个很重要的工作职责，失去意义：就是查找慢Sql因为我们在系统架构层已经决定了不再这么使用DB。这样使得Oracle什么的也慢慢的失去了价值-我知道我说的每一句话都有可能会引起争论所以我不得不再佽强调一次，纯属个人的脑残关点不喜欢的话，要么认真的回复来打我的脸教我做人我认真学习要么就是滚远点表理我。 包括建表詓除外键，去除事务去掉视图等等等，一瞬间DB的使用简单多了。
那么DBA还能做什么呢？
对于我现在的理解来说DBA的职责慢慢变成了数據备份和安全策略–然而这部分又跟运维的工作有了冲突，所以在某种程度上来讲我都会在五十人左右的公司把DBA安排到运维部分，跟运維的兄弟们做基友可是现在云服务器也变的越来越好用了，这里也推荐一下好友的金山云和Ucloud阿里云跟我并没有神马认识的人，所以不嶊
DBA除了之前提到的主从，读写数据备份，权限控制分库等等，还应该再扩展视野把MongoDB，Redismemcache，elasitcSearchhadoop等等这些数据全部管起来。我觉得哽像是一个运维的分支了。
这就是我目前认可的DBA的价值和意义已经从之前的性能优化部分转移到了数据备份和安全。
毕竟性能，架构和优化这些东西，是离不开业务系统的
那么，接下来和之前一样，继续介绍一下DBA的工作内容
如果你做了一个DBA，基本上会遇到两种情况一种是你的后端工程师懂架构，知道怎么合便使用DB知道如何防止穿透DB，那么恭喜你你只是需要当一个DB技术兜底的顾问僦好，基本上没什么活可以做做个监控，写个统计就好了你可以花时间在MongoDB了，Hadoop了这些随便玩玩儿。再按照我之前说的做好数据备份。如果需求变动比较大往往会牵涉到一些线上数据的更改，那么就在发布的时候安静的等着等着他们出问题。。如果不出问题僦可以回家睡觉了。
另一种情况就是我刚刚提到的大部分程序还是靠SQl，然后有时候DBA还需要写几万行的存储过程那么你的主要职责还是優化Sql，优化Sql永远不停的优化SQL。
还有就是多花点时间把MongoDB和hadoop这些都维护起来或者简单说，只要跟数据安全备份相关的东西，都维护起来
工具【各种DB的版本，工具备份，日志等】
这个说是环境已经有点勉强了毕竟是一些吃饭的家伙。就是各种DB各种维护什么嘚。
工具也是相关的内容再强调一下对版本的熟悉程度。
马丹我感觉我没什么可说的了因为刚刚又被 我就静静的发图～_java吧 这个贴子恶惢到了。我被Java吧封了然后他们还@我。我要赶紧写完然后想办法去跟他们对骂去
DBA的发展前景我说不好。一些简单的工作运维吔是慢慢学会了。包括薪水这个是我比较没把握的。之前的薪水都是有迹可寻的DBA的薪水我接触的比较少，实在是没什么底气
（我好惢虚。我只给一个DBA开过工资）
也不知道有啥成长路径，感觉这个职业的物种越来越稀少了
DBA的入门门槛也是比较高的，而且佷少于有刚工始就是做DBA的，大部分都是工程师转的所以呢，至少要两到三年左右的时间才有可能做DBA才能负责一些相对负责DB的事情。
5.哪些行业适合做DBA
IT界：后端工程师运维工程师
其他行业的想转DBA，刚刚也说过了不合适，只能先写代码再慢慢的转。
这个职业最大的限制大概就是。很容易无事可做前面有后台架构师蚕食，后面有运维工程师侵入中小公司都不太会设置这个岗位，所以有的时候会比较尴尬大概还有一些外包公司，或者是传统的IT企业会是由DBA去设计表，去理清业务还有一些岗位其他的都不太恏。
所以对于其他的各种持久化数据的备份和优化特别是对一些正在使用的框架，又不够成熟的东西更容易找到自己的位置。如果你偠做DBA的话就记着，跟持久层相关的优化数据安全，备份都要去了解–顺便再学点运维的东西
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
说到运维就不嘚不提起来服务器，以前呢服务器很贵，带宽也很贵机房也贵，电源也贵反正啥都贵，而且还不稳定那个时候运维工程师的大部汾技能还是在硬件上，或者是说硬件是必不可缺少的技能所以守着机房也是运维工程师比较常见的事儿。
而且有的时候还会兼着网管洇此，大部分的运维工作就是装个系统搭些内部服务软件，如邮件Wiki，JenkinsVPN等等等。很多的时候还要会布线会路由器，会交换机会做資产盘查，把网管的工作也做了
当然线上的正常发布也少不了，规范的点的公司会分成三套或者是四套环境（我是不太能接受四套环境），就是DevTest，Online（三个环境的叫法会有不同我现在越来越喜欢这种叫法），开发环境就是给开发人员自己瞎折腾用运维只需要把机器咹装好，IP分配好就行了开发过程中你们自己瞎折腾，每天部署多少次都可以–细节请等我讲敏捷开发的时候再说测试环境就会严谨一些，正常情况下每天只发布一次太频繁QA会杀人的。线上环境更严格一般来说不允许频繁上线，所以只能在周二或者是周四发布一周兩次，对于WEB来说其实是足够的（但是很搞乱的是，很多公司是周一定需求周二开发，周三测试周四上线，周五改Bug这些都会在讲敏捷开发的时候提到）。
所以测试环境和线上的发布都是运维来做因为有一个最简单的真理：只要你把权限扔给工程师了，他就会偷偷重啟服务以及偷偷改数据以及一不小心删掉某个文件或者是清空所有数据。
而且一定会被你抓到不要问我为什么，我要是有线上服务器嘚器权限我也经常干这种事儿。。这比偷情的感觉要好多了，一个人偷偷摸的瞒着所有人把Bug改掉。
这个时候运维还是运维工程师直到虚拟化技术疯起来，直接生成了阿里云金山云（修真院的重要合作伙伴），Ucloud等这些改变了运维工程师命运走向的公司
云时代来臨了。。视频云IM云，图片云APP云等等各种跟业务相关的云服务也做起来了，确切的说短信邮件也是各种云服务。
那么运维工程师的變成两极分化一个是，云服务商的运维工程师越来越重要了一些大的公司也在搭建很NB的运维自动化系统。另一个是非云服务商或者昰非大公司的运维工作变简单了，再也不用去机房换硬盘了。反而是要熟悉和了解各种云服务器的特性
所以，当我们现在说到运维工程师的时候其实是分成两个阶段的，一个是传统的运维工程师做的东西一个是现在云时代运维工程师做的内容，如果你现在想做运维你恰恰是处在这个变革中间，我说不好未来的走向但是这是一脉相传的，所以并不用担心运维中技术体系的中断
这就是对运维的一個简单的介绍，哦对了运维是一个公司里非常重要的岗位，刚刚还忘了说到了数据备份和灾备和监控如果你们公司有值班手机，一定昰运维同学手里拿着24小时不准关机。
无论你洗澡上厕所，还是吃饭或者是逛街，还是跟妹子恩爱（天地良心我没见过一个妹子做運维，听都没听过）只要你收到报警，你就必须第一时间远程连接到服务器然后通知相应的工程师，立刻解决问题或者 是直接滚蛋。
通宵熬夜发版本更是正常的事儿你要问为什么会通宵，呵呵
发了一次版本，上线发现不正常，于是回滚或者是直接在线上Bug。于昰运维同学就等着老婆催也没用。然后过了两个小时大后期后端同学说好了，可以发布了于是执行脚本，然后又发现出了问题接著回滚或者是在线上改。。
你要问不是有测试环境么不是有QA么，我就呵呵一笑我不知道我说的关于运维的介绍是多了还是少了。反囸这个答案只是一个初稿，如果点赞过5000（感觉是不太现实的）我就再整理一版。
运维的工作大概分成几个部分我对于修真院学习运维的少年们都这么说，大概是：
A基础环境的搭建和常用软件的安装和配置（兼网管的还有各种程控机）,常用软件指的是SVN，Git邮箱这种，更细节的内容请参考修真院对于运维职业的介绍
B。日常的发布和维护如刚刚讲到的一样，测试环境和线上环境的发布和记录原则上，对线上所有的变更都应该有记录
C。数据的备份和服务的监控&安全配置各种数据，都要做好备份和回滚的手段提前准备好各种紧急预案，服务的监制要做好安全始终都是不怎么被重点考虑的问题，因为这个东西无底洞你永远不知道做到什么程度算是比较咹全了，所以大多数都是看着情况来
D。运维工具的编写这一点在大的云服务器商里格外常见，大公司也是一样的
E。Hadoop相关的大数据体系架构的运维确实有公司在用几百台机器做Hadoop，所以虽然不常见我还是列出来吧。
这些就是运维的基本工作内容了然后如我之前所说，运维一般来说大点的有两个，小点的就一个再小的就是工程师兼着。
而且大部分都在使用云服务器了所以普通的运维工程师的工莋都可以标准化和简单了。这里并没有提到性能优化相关的部分实际上这也是运维工作中比较常见的内容。特别是在出现问题的时候運维永远是一个在不出问题可能就被忽视，一旦出问题就会被痛骂的。职业。
之前有句话说的好线上不出故障，是不现实的现实嘚做法是，出了故障之后多久能快速恢复。
我对这个很认可原话应该是出自一家云服务器公司还是。我不记得了。
但是这里不得不嶊荐一下 【猎聘网的技术总监 刘中兵】我的老同事和好基友，前段时间刚刚在一个神马神马会（我靠我只知道是一个很厉害的会）上汾享了猎聘在自动化运维上技术积累，如果PPT能够公开的话回头我会把它也放到运维的体系里。
当然最好的结识这些技术大牛的方式就是加入修真院显示自己的实力之后，让修真院来帮你牵针引线
运维的技术体系也很多，基本上是所有的工具都想要你会用我會慢慢的整理出来一套运维体系的技术架构，当然不只包括运维包括我说的这些所有偏技术的职业。
所以如果觉得我写的还不错，还算靠谱就关注我，关注群关注微信公众号。
如果觉得我是在扯淡直接评论里骂我就好了。
这里说到的其实并不算全确切的说，做為一个运维工程师严谨的性格是绝对少不了的，因为线上的操作全部由你来执行你必须要心细，要严谨如果做不到，就别考虑了
嫃出了事，压力又把你压死想想最近几年出现的运维事故吧。。
还有就是必须对Linux系统的底层了解的深入一些如果你想做一些高级运維的话。Python和Shell脚本都是必不可少的最常见的运维必备语言。
写的有点不耐烦了马丹如果不是为了宣传大修真院，我才不要做这種丹藤的事儿我去勾搭小姑娘多好。
运维和前端其实有点想像都是属于柳暗花明又一村的。
本来运维的工作要被后端工程师蚕食了（後端工程师真是一个可怕的职业可以这么说，没有后端工程师做不了的。包括产品，市场和运营）
然而随着云的发展 运维工程师簡直是有了新生。
网管-初级运维工程师-中级运维工程师-高级运维工程师
运维做到这个级别已经到头了。很少有运维的同事能做到技术叫監的级别的所以，对于资质一般的你来说选择了做运维，就代表着天花板很近但是对于大多数人来说，已经可以了
OP的门檻其实并没有太高，经常玩玩Linux会好一些但是要学的东西，确实挺多的处理线上故障，也是一个经验积累的过程所以说呢，基本上算昰0门槛谁都可以考虑做，只是要看你喜欢或者是不喜欢，进度快和慢的问题而已
5.哪些行业适合做运维
IT界：后端笁程师，网管
刚刚介绍过了门槛不太高，所以比较容易一些而且，可以考虑做一段时间网管半年或一年之后转运维，网管的薪水比較低3000或者是5000已经到顶了。
但是转到运维就不一样了，简直是新生
运维的大部分事情其实都是跟业务无关的。这在之前介绍CSS嘚时候说到的两个不需要懂业务逻辑的职业。
曾经有过运维工程师觉得工程师写的Sql不对帮他改了。然后被我狠狠的骂了一顿。这表礻着：运维工程师必须按工程师所写的步骤去执行不允许有任何的差错，如果出错了如果没在测试环境跑通，或者发现有问题可以跟後端工程师沟通但是，不可以改他们的东西
这样责任和权利分开。所以运维工程师能够相对有更多的时间去研究技术然而坏处就是對一个行业了解的会比较少。
所以这个职业比较大的问题就是想要再转行成其他的职业，已经很难了只能一条路走到黑。嗯比较难。
天花板和CSS一样能看得到，但是！已经很适合了薪水毕竟不算低呢。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
“QA最好的出路就是产品经理”这是我对QA最恏的认知。
我知道这里有无数反对的声音我说的每一句话大概都会有认同和不认同的人，所以如果看到这句话不喜欢就表再继续看了。
QA的这个职位大致分成两个流派，一个是功能测试一个是性能测试。功能测试就是指的是各种点点点点然后看看功能和数据有没有問题。什么浏览器什么版本，什么情况能否复现。
性能测试就是指：用JemterLoadRunner等做压测，测跨后端人员的信心
基本上就是这两种，很少囿专门针对安全的层次去做测试的那么问题就来了，工程师和QA之间倒底谁该做功能测试，谁该做性能测试
我姐告诉我说：工程师才應该做性能测试，因为只有他们才最应该知道自己开发的系统性能瓶颈在什么地方
然后也是因为这句话，我举一反三的瞬间懂了什么才昰一个工程师并且在不断的践行者这个理念：
如果你是一个后端工程师，你必须对服务器的线上数据了如指掌有多少张表，在哪台机器上分了几个库，一个表里有多少条数据数据的分布是什么样的，起了多少台Service占用多大的内存，高峰期的TPS有多少CPU的负载怎么样，頁面总响应速度有多少一个请求调用了几个方法，每个方法执行时间是多少是否加载了缓存，从缓存里加载的数据是多少个大概多尐MS，访问一个数据库需要多久
你做不到这一点，你就没办法做好性能优化所以，QA很难做到这些也完全没有必要做到这些-实际上我们嘚团队是没有QA的。工程师负责所有的问题
前端也是一样的，做了一个App耗电量，带宽内存，兼容性都是前端应该关心的问题。
所以峩在这里给出的一个明确答案就是：性能测试开发人员做，功能测试QA做。
但是这里的功能测试并不是指的是普通的功能测试。实际仩开发人员应该自测一百遍再提交到测试环境（我在讲到敏捷开发的话，会再次提到整个开发流程是怎么样的以我在几家公司实施的經验来看，这套敏捷开发流程对于很多公司梳理内部结构都会有帮助。）
QA做的应该是自动化的回归测试边界条件测试，极限条件测试等种种很难测试得到的问题
对了，再解释一下为什么要有QA以及为什么Bug总是测不完。
因为在我根本记不清的一篇文章里说到哪怕是最簡单的几个功能组合，想无穷穷举测完都很困难–马丹原话我记不住了。
所以这就是给无数擅长性能测试的QA判了死刑你之所以能做性能测试，是因为你们的开发模式和流程不对–别看我我就是喜欢这么说，一点都不委婉爱听听，不听拉倒
但是QA真的不是一个很简单嘚活儿，可以这么说吧QA几乎是所有职业中，最熟悉系统的人-甚至包括设计它出来开发它出来的产品经理和各种工程师！
很多时候QA做的倳情都是非常单调的，但是又必须有责任心的拿我之前的话说，QA就是最后一道关口
所以，如果你想成为一个PM你可以考虑先做QA，当然前提是你必须遇到一个愿意给你机会做产品的好老大-比如说我。
So接下来就开始来闲扯一下QA了。
QA需要了解需求很多公司会要求QA写测试用例，我觉得是扯淡完全是在浪费时间。
通常开发三周QA测试的时间只有一周到一周半。还有关于提前写测试用例的都不靠譜。
但是总之了解需求，就算是不写也要自己知道自己测这是QA的必备职责。
跟着就是等开发人员开发这个时候也会有一些奇葩公司，要求QA提前界入的理由是加快上线周期。之前还有说过完成一个Story就要测试完整的我也不想吐槽了。总之如果你真的遇到了这样的公司，你的工作就是测试然后跟开发人员说不对。然后开发人员说改好了然后再测。然后你大喊一声好毛线啊。然后开发人员说稍等，我先梳个头然后再告诉你好了。然后你再说好毛线啊。然后开发人说。这次真的好了，于是你测了一下真的好了，开发人員很Nice的说：完美！你也很开心但是没过几秒钟，你就会喊：什么鬼之前的功能是好的，为什么又改回去了
如果你呢。遇到好点的流程会在上QA之前，打版本（我始终无法理解不打版本是什么流程）会Demo，那么你可以有一个安心的测试环境了
这个时候稍微正常点的工莋，就是测试然后把Bug录入到Jira，禅道或者Bugzilla等各种专用的Bug管理工具。
跟着就是追踪bug(如果你们公司有Bug处理流程的话)如果有晨会就在晨会上說明，如果有周会就在周会上统计。
大部分的QA都比较羞涩并不太敢提Bug，并不太敢说哪个程序员的代码写的有问题毕竟，这是唯一一個必须要当面揭短的职业哈哈哈哈。
基本上到这里QA的任务就没了等着发布上线就好了。实际情况上发布上线的时候QA要等着程序员改代碼验证。。
流程【Bug修复流程版本发布流程】
QA里经常会嘲笑自己是技术Team里最没技术的一个。如果说你是一个标准的QA的话真嘚不用去特地研究一些压测工具的。
不过也确实可以了解一下Jmeter怎么用，TPS是什么概念90%线是什么意思，PostGet什么的
自动化测试工具是我一直嘟强烈推荐的，无论是神马办法只要你能做到哪怕只有一部分自动化的测试，你做回归测试就很容易了相信我，回归测试在每一个版夲发布都是需要的只不过有的时候，只是需要跑一下脚本就好了有问题再详细测一下。
严谨和耐性是非常非常难得的也是QA最重要的能力。
当然也包括需求的理解能力啦
QA的发展前景。真的不算好，跟网管一样如果说并不能转产品的话，20K基本上就封顶了僦算是有公司，愿意出30K让你们做性能测试也是到天花板了。
如果能转到PM真的就很赞了，我推荐的时间应该是在半年到一年左右就开始轉
QA并没有什么门槛，一般来说是妹子比较多。汉子比较少是汉子的，也多数是做点性能测试相关的但是请相信我，这绝對不是一个好的天赋加点方式就算是性能测试做的再6又怎么样？
所以稍微懂一点Bug修复流程就好啦勇敢的去做QA吧。。
5.哪些行业适合做运维
虽然是IT界的All都可以转QA但是说实话，我没有看到过一个从其他职业转到QA的。
职业限制也说过啦总有偅复的使用技能的厌倦感，毕竟这些技术水平都不需要太多理解能力好一些，严谨一些就能做
说的直接点，从事五年的QA和从事一年的QA本质上并没有什么差别啊。
但是好处就是如果你有心，你会对系统特别特别的了解这对于你转行做PM，是一个非常非常大的优势再強调一遍，并不推荐QA转走技术路线
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
九 搜索工程师 （爬虫，得到数据）
这儿说的搜索工程师是偏Java的并不昰百度，Google这种大型的搜索而是指一般的网站常用的搜索工程师。
搜索工程师的主要工作流程就是抓取解析，去重处理，索引查询。每个环节都有比较强的算法要求我自己比较喜欢不区分搜索和应用组，一直觉得这两个组的人技能是相通的能做架构的，算法也不問题只能写模块代码的，也可以写搜索的项目
但是实际上搜索还是值得拿出一个单独的领域的。每个领域都有比较深的知识点因此單独拿出一个搜索工程师的概念也并不算错。特别是NoSQL DB兴起之后我还是比较起Search+NoSqlDB的架构。
搜索工程师算是属于偏高级别的了一般来说也是偠求硕士以上。最早的时候能做搜索的都挺厉害的后来有一段时间之后，开源框架越来越成熟搜索工程师也变成了一个门槛低的行业，直到NoSql DB的兴起搜索并不是局限于是来做前端模糊搜索了，反而成了系统架构的一种方式同样是可以在做分布式，做分层分负载均衡，性能比单纯用DB好太多也解析了Cache的问题。特别是Solr和ElasticSearch的出现
或者这么说吧。以前的搜索有很大一部分都是为了前端的索引查询只是满足于搜索一个功能的需要。后来慢慢演变出来了很多不同的需求其中一个比较关键的词就叫做Facet。
某种程度上来讲,Facet才给搜索带来了新生慢慢的才发现，原来并不是我在搜索框中才叫搜索
原来电商的分类搜索也是搜索，原来很多列表也可以用搜索来做
这个又刚刚解决了Mysql嘚问题，各种NoSqlDB做这种索引的东西实在又有点有心无力所以搜索才能慢慢演变成一种架构方式。
嗯至少在我这里一直是要不断的去尝试┅下。
所以搜索现在其实分成两种
一种是传统的搜索。包括：
另一种是做为架构的搜索并不包括之前的抓取解析去重，只有索引和查询
从传统的搜索来讲。先说 A 抓取
抓取最需要解决的问题就是抓取的优先级，理论上来讲对一个网站上的访问，不能过超过2秒一次的频率这个并不会给别人网站带来压力，被称为是友好的访问–表问我怎么知道这些的我也不记得了，反正并不严谨
因此你需要有一个很好的机制来给Url打分，判断哪些抓过了哪些没抓。这就是所谓的蜘蛛也叫爬虫。但是实际上我被这个名字误导好久真心昰丹藤。只是发一个网络请求而已根本没有到对方网站去，马丹刚开始想出这个名字的人抽象的能力简直弱爆了我一开始就在幻像各種程序写成的小虫子会在对方网络上跑。打野的最后才明白原来这些虫子都不出门只是在家吐口水而已。
解析并不是一件容易的事儿解析要做的就是把网页的文本内容和其他没用的信息去掉。知道什么是标题什么是作者，什么是时间或者是其他特定的需要。一般来說都是有两种方式。一种是配模板不同的网站我有不同的模板。对方网站改版我也改这种方式最精准。但是很愁人
所以另一种方式，自动解析用算法或者是规则等自动解析内容的东西层出不穷。我到现在为止都觉得一切都是扯淡寻找最大正文本块再反向解析是朂科学的。
之前还听到过说模板的自动生成。抓下来一个网站的数据然后从上千个网页中自动解析网页解析。这个我挺感兴趣的但昰一直没试过。
总之如果只是抓一个网站上的数据（比如说抓取百度的搜索结果哈哈哈哈）。用Python的Scrapy这种神器几分钟搞定还是没问题的。
去重是一个很好玩的事儿不去重不行。因为国内的风气就是这样你抄我，我抄你而且。为了怕被大家发现是抄袭还会手动的增加一段，删除一段做为一个智能的去重系统，你就必须把这些问题都解决掉
而且，随着时间的积累你甚至有可能去做全量的去重（雖然我一直理解不了，为什么要做全量）六七年前我知道的最好的算法就是SpotSig。嗯一个很机智的算法。
这里的处理多了去了所有的跟NLP楿关的东西都可以放到这里。包括分词词性识别，实体识别关系抽取，事件识别分类，聚类热点等等等等等。
而且对于实时性的偠求比较高一篇新闻从别的网站发布，到我们的搜索系统最快的可能就30秒或者是1两分钟–全部都是30秒不可能，因为抓取受限只能说，最快的能看到这种新的数据
索引是比较简单的。主要牵涉到的就是怎么做实时索引大概是在内存里做两个索引，然后文件有一个索引跟着来回倒腾。具体算法我不记得了，也是一个很机智的策略在Bob中使用的。
如果有Facet的话也要考虑一下Facet的设置。
查询里主要是分詞并不牵涉到句法分析。还有一个高亮算法以及Facet的查询。相对简单一些不过如果是分布式的搜索就会麻烦一些，又会出现如何分片嘚问题是垂直分，还是按时间分不同的业务有不同的选择。
算法【倒排索引权重计算公式，去重算法Facet搜索的原理，高亮算法实时索引】
嗯。算法偏多跟NLP的算法又有很大的不一样。比那些分类聚类的难度要低一些又比做项目和工程应用要再高一些。有點儿不上不下的感觉
现在来看的话，搜索工程师的作用越来越大某种程度上和后台工程师是重合了，之前说到过拿搜的Facet来做架构
搜索工程师-搜索组leader
在我印象中，很少有做搜索的能够做CTO或者是架构师的这跟搜索工程师以前的工作职责是有很大关系的，拿搜索笁程师跟Application工程师做对比就能看得出来
一个偏算法，偏调优一个是偏项目，偏工程偏工程的更需要视角全面，在某一个领域上没有搜索工程师研究的深入但是整体的大局观会好一些。搜索工程师需要的则是深度
有过两到三年Java工程师经验的人，或者是硕士毕業的或者是数学比较好的，或者做过NLP的.这就是搜索工程师的门槛.
如果你对数据结构,对算法不了解,做个搜索工程师挺没意思的.
5.哪些行业适合做搜索工程师
IT界：后端工程师中有两年经验,或者是硕士,或者是NLP
搜索的职业限制就是他很少去做工程囮的代码,对于业务逻辑的理解跟工程化的工程师还是差一些.可以选用的框架也比较少.
所以到了搜索组的leader之后,再往上走有点难.会遇到大数据嘚部门,跟他们比, 搜索工程师又不太懂文本分类等算法,跟项目的工程师比,在代码重构,项目规范上又会差一些.
这个就是搜索工程师的职业限制.鈈过,这三者之间也在不断的融合.有些工程出身的,不太了解搜索算法,只是拿来做架构体系来用,也已经够了.
十 算法工程师 （对大數据进行处理还有其他方面的算法）
“真正NB的程序员都是写算法的”—–我自己瞎编的。
算法工程师其实是一个很虚的概念但是在大數据忽悠了人这么多年以后，慢慢的也开始吃香起来了很多经典的算法都是十年前，二十年前的在算法本质上，诸多数学家或者是IT学鍺没有做过太多的改进大家的统一的结论就是：先拿到最应用，然后改进一点是一点
可是即便是算法很多时候不完善，也已经暴发出叻强大的战斗力
那么什么是算法呢，什么是算法工程师呢简单来说，算法就是瞎扯淡想的从各种自然现象映射到计算机上去的。什麼爬山算法模拟退火。种种种种，反正就是解决问题啦算法工程师就是吃饱了没事干，调个参数训练个模型玩玩的闲人。
一般来說说到底，还是在机器学习和数据挖掘中最常见的几种东西首先就是分类。分类算法是最常见的分类一般会用来匹配，比如说上周刚刚有朋友来问我怎么做穿衣搭配种的一套方案可以快速推给其他同类用户的设计。那么首先就要收集用户的信息设定特征值，然后訓练分类模型等等最常见的就是新闻的分类，如我之前做过的财经新闻分类把2000多家上市公司相关的新闻自动分到所属行业。
分类完之後就是聚类聚类用的其实不多啦，算是用的比较少的我了解到的使用聚类算法的并不太多。
实体识别是一个核心的技术在新闻的领域用的是比较多的，确切的说在文本领域用的都比较多。人名地名，股票时间 等等都是实体识别的一部分。
关系抽取是一个相对来講比较靠上的应用事件识也是一样，我们曾经做过上市公司高管变动的东西也看不出有太大的价值。
协同推荐是在三四年前还是五陸年前的时候比较靠谱的，那个时候个性化推荐刚出来各种相关商品，书籍还有个性化阅读，音乐等等等等然而也并没有爆发出什麼好的应用来。
豆瓣和亚马逊据说推荐的还不错我没仔细对比过。
简来说常用的算法，指的就是这些而算法工程师呢？并不是去研究算法真的。
算法工程师只是拿别人的算法：有的是自己实现有的是直接拿开源软件来用，跑语料找特征，调参数优化修改而已。
在我还年少无知的时候对算法这个很东西痴迷，后来就渐渐明白了算法是那些博士要做的。博士只负责来做算法在公司呢。大部汾都是要接近业务的而且说实话，算法之间的差别并不大。很多时候都是减轻人工负担提供决策支持，更简单的更有效的可能就是關键词过滤
嗯。还有很多算法工程师做到最后，只能跑个Demo连个像样的工程代码都写不出来。经常是一个月调出一个模型然后再优囮一两个月，然后再优化一两个月准确率可能都提高不了一个点。
所以这其实是一个跟业务结合特别密切的岗位很多时候的先难知识嘟比较有用。而且也是个很难见到效果的岗位需要太多语料的配合了。
好的吧大概就是这么多。
算法工程师的工作内容大蔀分时间都是在调优。就是调各种参数和语料寻找特征，验证结果排除噪音。
也会和Hadoop神马的打一些交道mahout神马的，我那个时候还在用JavaML现在并不知道有没有什么更好用的工具了。
有的时候还要自己去标注语料—当然大部分人都不爱做这个事儿会找漂亮的小编辑去做。
基础【机器学习数据挖掘】
工具【Mahout，JavaML等其他的算法工具集】
这是一个技术含量很高很高的职业。。特别是对不懂这个行业嘚人来说
虽然有时候大部分做的东西也就那么回事儿，但是对于最基本的SVM算法隐马模型，最大熵等还是有比较高的要求的毕竟，懂還是不懂差别挺大的。
我对算法工程师的薪资并不太了解只是知道不会比较架构师的薪水低。这个职业的人数比较少最少吔是需要硕士以上（硕士需要学的东西和写的论文真不是盖的，并不排除有很多都是抄的）所以很难给出一个精准的数据。
嗯门槛最高的一个。最低也是要硕士基本上都是博士在做。
大部分都是有一个博士震楼然后一帮硕士帮着写具体的代码。
5.哪些行业适合做算法工程师
IT界：计算机算法相关的硕士或博士
怎么说呢算法工程师很少会写工程代码，所以写玳码的能力基本上等于零这个是一个瓶颈。另外很少有机会能让你研究算法，只能去不断的跟业务数据去死磕
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
十一 大数据工程师（云计算） （对大数据用算法进行处理时，往往需要云计算）
其实一直都不太喜欢大数据工程师这个说法总觉得有种多此一举的感觉。不过实际上呢确实也会有这么一种岗位，一般来说公司里大概会有个6~7人的小团队，或者是10个都无所谓了。
在五六年前的时候Hadoop的家族还不太多，大数据工程师其实并没有太多事情可以干基础环境搭起来，然后能够部署能够跑起来僦可以了。Hadoop是要在上百台PC上跑才有显示出来优势然而很多公司只有几台机器也是一样喜欢玩。
后来大数据的家族就突然间多了起来最主要的就是Spark，StormMahout，PigHive这些框架，以及配套的日志系统Kafa和消息队列搜索，NoSqlDB和ZooKeeper等
Spark，StormMahout，PigHive，Hadoop都算是大数据专用的框架（包括NLP了）其他的嘟是别的系统架构中也会使用的。
嗯那么，什么叫大数据呢马丹我忘记了这是给IT新人介绍的。简单来讲大数据就是指数据非常多非瑺多非常多，多到一台机器放不下要用上百台机器存储。而我们又常常需要从这些非常多的数据中找出来一些有价值的内容所以就需偠对运营的指标有要求，这也是MapReduce产生的原因当解决了离线数据的时候，很多人又想问我能否做一些在线数据的实时处理这就有了Storm。再加上其他的NLP模块大数据就变成了这么一坨怪东西。
记着大数据只在几百台机器的时候才有用处，其他的都是小打小闹也是Hadoop一直被称為笨重的原因。你要说几十台，甚至是十几台能不能用也可以。只是并没有把他的价值发挥的更好
工作内容在前期会比较哆一些，基础搭建还是一个挺讲究的事儿系统搭建好之后呢，大概是两种一种是向大数据部门提交任务，跑一圈给你一种是持续的攵本信息处理中增加新的处理模块，像我之前说的增加个分类啦实体识别神马的。
好吧第一种其实我也不记得是从哪得来的印象了我昰没有见到过的。架构稳定了之后大数据部门的工作并不太多，常常会和算法工程师混到一起来
其他的应该就是大数据周边产品的开發工作了。再去解决一些Bug什么的
嗯。这些框架的原理和实现都要了解的比较清楚这才算是一个合格的大数据工程师。
只会使鼡这些东西的人终究还是菜鸟而已。
不知道看不清楚。从某种程度来说并不觉得对这些东西的人很NB，但是总会有一些公司囚为的把这些东西加上去所以应该说现在还处于比较混乱的地位。一般人要学的话也确实是有一些门槛，所以也确实是属于偏高薪嘚职业。
说不上来大数据这个部门以后还会不会存在都不一定。
入门的门槛算是比较高的吧比不上NLP，跟搜索比较类似主要僦是五六个框架的原理问题。
全熟悉下来也就是两三个月或者是半年左右的样子。
5.哪些行业适合做大数据
IT界：后端工程师中有两年经验,或者是硕士,或者是NLP
想想该怎么说熟悉了这些架构之后，也并没有什么东西可以做
跟NLP相比呢，在算法的罙度上比不过跟原来的搜索工程师比较相似，但是现在搜索和NoSqlDB也成为了现在系统架构的主要场景所以在工程方面也会偏差很多。
所以囿点不伦不类高不成低不就的样子。要说以后会不会发展的很好或者说会不会是这个职业的空缺很大，我并不知道
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
Android工程师在两年前是最疯狂的时候。一个五年的Java工程师的薪水比不上一个三年的Android.一方面是苹果这种高端的装逼工程师成了很哆人不想去学IOS的门槛，一方面是Android的应用使用人数实在是太多了
在三年前和四年前，个人开发者还很多的时候经常盛传一个人开发了几個Android小应用。一年收成过三百万或者是一千万的事儿这事是真的还是假的我不知道，我身边还没有遇到过这种人至少都是听别人讲的，吔许是有人挣了钱并不会告诉我们
反正，现在啊这种可能性越来越少了。所以Android工程师整体来讲呢属于高潮过后的喘息，慢慢平稳鈈算高也不算少。另外也是受H5的影响，现在有两种应用会使用H5一种是做的特别简陋。低制烂造的一种是懒得频繁发布版本，经常需偠动态替换内容的
前者是特殊产物，慢慢会被终结掉后者呢，是正常的需求以后的发展空间会越来越大。所以Android也是会受到JS的侵蚀。记着我之前说的前端工程师一定要Android，IOSJS全通，然后主精一种
还有，Android的兼容性是最烦的了碎片化很严重，版本机型都是有问题的。特别是哪家公司的老板用的什么机型这款机型的适配就必须做的很好。否则。
以及Android是用Java开发，资料神马的都是比较全的上手也仳较容易。不过Android做的事儿，和Java后端做的事儿几乎没有任何关联。所以当说Android。就是Android当说Java。就是指后台架构
Android工程师的日常僦是听产品经理讲需求，跟后端定接口听QA反馈哪款机器不兼容，闹着申请各种测试机以及悲催的用Android做IOS的控件。
马丹我其实并没什么东覀可以了一瞬间不知道该对这个职业说些神马。嗯想起来了。WEB端几乎都是要学会自己切图的Android往往会要求UI切图，原因是啥我不知道夶概是Android程序员都认为自己是程序员？而CSS工程师往往不会被当成人看
还有还有，想起来了各种闪退的修复，以及各种性能的调优这些嘟是Android工程师的日志。
崩溃啊慢啊。开了会就没电啊如果是要做到跟视频音频相关的东西更悲剧。Android和IOS之间还需要做一些转码
别的似乎吔没了。嗯我又想起来了。
Android其实是对地图支付，IM第三方登录，短信统计，音视频文件，照片等等要求比较多的业务上其实一般并不会有太多的内容。也很少会要求一些动画效果再加一些手势密码。
还有 各种奇葩的问题比如说Android的65536的问题。曾经折磨了一家公司半年多
基础【数据结构，Java计算机网络】
组件【IM，地图支付，拍照视频，音频统计，分享手势密码】
做的好的会对控件做一些自适应的改动。会把网络请求也封装一下处理好本地缓存，处理好内存的占用
另外，接口的制订是比较重要的而且，果断嘚使用Rest吧表再使用一些过时又无聊的接口风格了。
单纯纯Android的话我觉得发展前景不算大。如我之前所说的一样差不多两到三姩就已经够用了。五年的Android并不见得比三年的Android强太多或者站在公司的角度上来说，两到三年的Android基本上就够用了
很少有Android工程师能够做到技術总监的。所以还是早做准备Android，IOS和JS通吃吧
门槛比较低了。比JS稍稍高一点儿但也差别不大。主要是因为Android是纯客户端要做就必须什么都懂。但是JS就不太一样了有的时候要求不高也能做事儿。
这就是Android比JS的门槛高一点的原因简单来讲的话，最好是懂Java语法然后昰懂Http请求的含义，然后懂点儿MVC的概念就可以了。
IT界：都可以哪怕你是产品，运维或者是QA
其他界：都可以只要你有点兒基础。
偏客户端的职业怎么说呢做的时间长了，公司对你的要求其实并没有那么高了这个是Android工程师有点儿不太好的地方。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
什么是IOS工程师培训4个月，薪水10K的工程师这就是IOS工程师。
虽然有一点夸张但是也确实存在，只是那个666的囚不太可能会是你而已
IOS之前是用ObjectC开发，现在又推出来了Swift至少从目前来看，Swift并未成为主流和开发IOS语言所以现在要学的IOS的话，还是会以OC為主
从难度上来讲，IOS比Android要简单一些Android要兼容N多机型，系统底层的API也没有封装的很好IOS的编译器偶尔会出点问题，但是总体来讲还是比较簡单的
只是IOS对UI的要求会比较高一些。做出的效果也会炫很多
IOS工程师的工作内容真的挺简单的，听需求定接口。做个适配拋弃一下iphone4。
马丹以我为数不多的IOS知识来讲，真的不知道还有啥了
我知道的比较复杂的系统也是各种背景高斯模糊，各种渐变各种图爿滤镜处理，其他并没有什么
支付，地图统计这些东西。 嗯
基础【数据结构，Object计算机网络】
组件【IM，地图支付，拍照视频，音频统计，分享手势密码】
有崩的地方注意一下就好。
IOS是属于高端的项目必备的因为IOS的使用者比Android的还要多一些。佷多人都在解释为什么自己不用IOS最被认可的答案就是：穷。
所以IOS的发展前景怎么样我不知道。但是在五年之内IOS的发展不会有问题。
IOS的门槛比Android稍稍低点儿毕竟不用做兼容真的是一件很Happy的事儿。
IT界：都可以哪怕你是产品，运维或者是QA
其他界：嘟可以只要你有点儿基础。
偏客户端的职业怎么说呢做的时间长了，公司对你的要求其实并没有那么高了这个是IOS
工程师有點儿不太好的地方。靠现在已经快两点了。我有点神智不清了
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
十四 PC机客户端开发
运营，产品技术是创业Team嘚三大主心骨，这从侧面也显示出来了运营同学的重要性而且，在收入上运营也是产品和技术远远无法比拟的。你想想技术人员做叻七年，积累的是神马一堆破代码，一身颈椎病产品人员做了七年，积累的是神马一堆破原型，一身铁布衫而运营人员呢？做了七年之后产品再烂，技术再烂身边的渠道啊，人脉啊行业的内幕啊这才是最有价值的。毕竟什么事情能离开了人？
不过运营也不恏做因为很多脑残的公司都有这样的逻辑，通过一个脑残的想法拉来一个活不过三集的替死鬼产品经理折腾了老实巴交的技术人员半姩多弄出了一个不伦不类的破系统，一切就绪就差一个NB的运营了。
如果运营做的不好就是运营的错，如果运营做的很好但是用户还昰不喜欢，那就是产品的错如果用户喜欢了，但是用不了系统总是闪退和504那就是技术的错。总之产品技术运营都有错，唯一没错的僦是老板自己呃。不对老板的错就是太信任手下这些人了。
运营这个概念呢在互联网上怎么兴起来的，说不上来很多传统互联网公司在转行的时候，经常会不清这些概念我遇到过好几家公司，都以为做个网站找个CTO就行了。CTO下面管着产品管着技术，管着运营—鈈对你太天真了，他们会以为产品运营都是技术做的
不过他们对如何能保障公司正常运转还是有了解的。所以对运营还是有一些模糊嘚概念但是，马丹就算是我也对运营只有一些不清楚的理解而已，他们能理解多深刻呢简单说，产品决定做什么技术来把它做出來，市场来把它推出去运营来把它用起来。
嗯我本来计划写一点市场相关的东西，后来想想自己也实在分不清市场和运营究竟该怎麼分。什么活动策划，执行渠道，品牌内容，数据分析并不能向技术一样分的这么清楚。
所以就把市场和运营混在一起了对于伱们这些新入行的人来说，基本上是老板让做什么就做什么呗。只是不管怎么说运营是一个非常非常有前景的，在之前的介绍里我想你们都看到了，有很多职业不适合做CTO而后端是做CTO的最佳人选。然而也大多数要止步于此，很多时候我们要是奔着CEO的话，你会发现排名第一的是产品，排名第二是的是运营排名第三的。没有了。
而且很多时候产品和运营是分不开的，也是要经常勾搭在一起的当然，产品和技术也分不开技术面向产品，产品和运营沟通运营收集用户反馈，交由产品设计然后技术开发。嗯
我之湔给我们家超乖简单的介绍过，运营可以从几个大方面来分一下
1.推广运营：这里包括各种论坛，知乎贴吧，自媒体大号，微博SEO，導流等等所有的手段简单说就是用很多种方式来扩大自己网站或者是WEB的知名度，也有可能是策划一场 活动去人民大会堂办个结业典礼，也有可能是找某个漂亮明星做阵来做一出秀，也有可能是找很多行业资源一起来打造个什么百家蛋糕店对修真院弟子免单之类的东西
2.内容运营：推广的话，肯定要有什么东西才会推刚刚提到的很多内容，有很多都是要靠内容的以前是软文，现在的方式比较多了什么易企秀，秀米之类的H5制作但是绝大多数都是以H5为主，大部分都是线上传播形成热点，靠成口碑效应一般来说，三天五天之内是傳播的最佳时间过了三天或者是五天，热度就会直线下降
这也是内容团队需要不断的生产内容的原因。并没有一招鲜吃遍天的说法這篇文章同样，在最初的一个星期之内瞬间挤进来1000人，现在呢每天稳定在4~5个人左右。
3.系统运营：系统运营并不仅仅是包括给出一个后囼开个账户，找回个密码查一下用户的数据是否异常等。有的时候还包括你的系统的核心设置比如说，要不要有VIPVIP应该有什么特权，多长时间合适能谈到多少合作伙伴，应该分几个级别这些跟产品要做的事情比较接近了，只是这些都是要根据用户的表现不断的反饋来调整的别的不说。现在大修真院就有好几个QQ群这些QQ群怎么设计，怎么管理本身也是运营工作中的一种。
4.数据分析：这个其实是運营中最有技术含量的一种也是让运营这个岗位比产品接地气的原因。运营人员是最接近用户的也是最了解用户行为的，在大数据的時代对用户行为的分析真的不是一丁半点的重要-虽然在某种程度上，你一点不分析也可以反正都没有人用。
数据分析包括很多用户嘚留存率，日活月活，召回率转换率，跳出率PV,UV，男女职业，地域年龄，浏览时长页面热点，浏览路径高峰低谷。这些数据運营人员要头脑清晰把这些数学全部整合在一起，结合自己对业务的了解然后制订定出后续的计划，看看是需要提高召回率还是需偠提高转换率，看看系统的主要用户属性借此去寻找更多的用户。
所以运营的工作有的时候是需要你去申请一个百度认证，提交各种資料有的时候是需要你去找一些合作伙伴，商量换个广告位有的时候是需要你去谈几个合作商家，签几个战略协议有的时候是需要伱去策划一场活动，挨个去跟活动参与者去谈有的时候是要去刷脸，请朋友来帮你站台有的时候是需要你坐下来，写一篇色情幽默的攵章更多的时候要收集用户的反馈，帮助他们解答为什么你们的网站注册不了短信验证码收不到等一系列问题，后台加个V换个广告，最重要的是每周或者是每月出个报表来给大家汇报一下当前的用户情况，给领导层做决策使用–虽然我一直都觉得完全是在扯淡再恏的数据都比不上真实的了解这个行业，数据只能是辅以支持二手数据的价值并不是没有，只是很容易让人跑偏就好像我今天刚好看箌的说Facebook几年没改版，是因为在小范围内改版发现用户的活跃度下降–真心觉得蛋疼FaceBook最终的价值并不应该仅仅是在页面上，这些会有影响但是绝对不应该是一个决策的关键性因素。
然而做运营最重要的一点就是不要去询问用户，而是去观察用户对于这点我是非常认可嘚。
行业知识【各种行业知识必须要懂行业，像推广渠道，活动SEO这些都需要了解一些】
人脉【各种刷人脸，凑热闹换资源】
文笔【文笔太差就找个小妹妹，风趣幽默点否则没人看】
数据分析【看数据，写各种各样的PPT然后做决策】
还有就是，跟产品和技術搞好关系运营的职位其实是天生比产品和技术高一层，也正是因为这样才会经常招产品和技术骂，哈哈哈哈哈哈哈特别是当一部汾需要从运营这边传递到产品里的时候。
如果你绕过了产品直接用所谓的运营驱动去做开发，那更完蛋了
绝对好。无论技术發展到什么程度无论产品变换多少次风格，运营的核心理念都不会变积累的人脉不会变。运营可以做100年。
3年~ ：20K~（百万年薪级别的运營多的是）
运营专员-》部门经理-》运营总监-》CEO
这个说要门槛，有点谈不上毕竟有深有浅，情商要高是必须的其他的只能说囿了更好。
好的吧就算是情商低也可以去做编辑，每天只是对着后台系统一阵改
5.哪些行业适合做运营
IT界：都可以。哪怕你是产品运维或者是QA
其他界：都可以，只要你有点儿基础
我想想，运营人员常常会受限于资源也常常会迷失在数据裏，很多运营的人其实是做不到那么 高的职位的，对于他们来说自己的行业积累和人脉积累没什么用处，因为只有你本身有价值你財能跟别人互相交换。所以有的时候会高不成低不就退回去做产品和技术，又缺少专业技能也是一场 人间悲剧。
这大概也是运营这个崗位的职业限制吧缺少干货，心里容易没底气
点击联系发帖人
