工具和语言其实没太大关系，但是也有关系。因为一旦选择了相应语言，必然有比较适合这个语言的工具链

1) 还有专门管项目的 SCM？ 甭管有没有，撸起袖子两个人一起干吧 2）项目看重，也的确需要就创建一个。如果根本不需要，建再多也没用。创建好相关 job 后，可把维护管理单独 job 的权限下放给项目组。

[i=s] 本帖最后由 laofo 于 2016-10-20 15:46 编辑

此岗位 title 为配置管理主管/经理岗，属质量保证中心部门，汇报对象测试部总监。部门分为测试服务部和配置管理部两个业务，其中配置管理部，包含配置管理经理 1 名，配置管理员 1 名。22-26K 工作地点在双井 E-mail：[email] wupeng@huizhongcf.com[/email] 18210280939（微信可搜索添加）

能不能贴文字，图片太模糊了看不清。

看提示是不是让你升级到 svn 1.7 以上？

第一，互联网是灵丹妙 yao 吗？

在这场互联网创业大潮中，创业者动辄高喊用互联网改变世界，动不动叫嚣 “去 ---- 中 jie”，“让信息和交易透明”，结果用户却发现，通过这样的平台实现交易，同样存在着个中不为人知的黑幕。当然，黑马哥不是全面否定互联网的作用，但是真正利用互联网实现信息对称，还是拿着互联网当幌子，结果迥异。

第二，是互联网 +，还是 + 互联网？

最近，黑马哥关注了好几个从传统行业转型互联网创业的项目，发展状况都是非常稳健。相比之下，很多宣称完全用互联网思维创业的项目，虽然刚开始发展势头迅猛，而后却慢慢无声无息，或者是倒掉了。因此黑马哥现在也是更看好有传统行业背景的人来做互联网创业项目，因为不管是教育、医疗亦或是二手车市场，水都很深，没有点积淀和能耐，很难趟过去。

第三、烧钱投放广告引流量这一招还管用吗？

纵观瓜子二手车开拓市场的策略，其实还是当年赶集依赖传统的广告投放和公关策略那一套。当年赶集和 58 同城广告大战，更多意义是传统形式的广告战，而不是围绕着 UGC、PGC 来运营。

现在做瓜子，杨浩涌还是沿袭了当年的营销模式。但是世易时移，当下的营销，更讲求与用户互动，通过各种不同的营销模式 “激发” 用户自发形成二次甚至多轮传播。

相比之下，瓜子花在广告上的费用的确不少，但是都变成了一次性的，而且是单向的传播，而没有很好进行联动，把广告变成多维度的展现和传播。这样一来，即使刚开始引流效果不错，后面也是难以维系的。

说到底，黑马哥觉得，其实创业的成功基因也是很重要的，虽然从个人创业的角度来说，杨浩涌算得上成功，但从运营公司的角度来说，只能算差强人意。经历了这场高层震荡后，下一步瓜子从人事上、从运营上、从市场开拓上会如何做出改变，黑马哥也是静观其变了。

级别 p6, 没有股票，北京高德

最近的确懒惰了

帅哥你去吧，我不得行。。。。不过据说最近华为云挖 jd 墙脚挖的厉害。 召集了一大票人

这个职位不错。支持一下。上海的朋友可以看看

原文如下

Written by Paul de Raaij on 20 July 2015 CONTINUOUS DEPLOYMENT OF OUR SOFTWARE

Just developing software is not enough. You’ll need to get it on production and you want to be sure that you deploy quality software and not breaking software. In this article, part of our microservices journey, I’ll describe how we have set up our deployment pipeline in a way that developers can do their own deployment complying to our standards.

LANGUAGE AGNOSTIC The deployment pipeline as we have created it is language agnostic. Which means that the process to assure quality and deploy software for a PHP application is the same as the process for a .NET application. The used tools for quality assurance and packaging might differ, but the process is equal. This ensures simplicity and reduces the cognitive load on developers to understand the process for all microservices, which might be developed in different languages.

DESIGNING THE DEPLOYMENT PROCESS When we start designing our deployment process we were looking for a solution that could support us in deploying high quality software. At that point we were already using GitHub and their pull-request system for our code versioning. What we wanted was a system that could verify the quality of the pull request, before merging it into the main repository.

If a pull request is validated and passed all checks, it should be allowed to be merged onto the master repository. All steps after the merge should be executed automatically and result eventually into a deployment on production. The diagram below displays a bird overview.

continuous-deployment.002

AUTOMATING THE PROCESS Each build step consists out of a set of actions which we define in the project itself. These actions are defined in ant build scripts and can be anything from creating a folder to calling a command line tool which does the actual inspection. These build scripts are not triggered manually. We use a build server to guide the whole build process. A build server is able to react on triggers and start the appropriate action.

For our build process we’ve decided to use TeamCity as build server. There are many (open-source) alternatives available, but TeamCity fitted our needs perfectly.

CONTINUOUS INTEGRATION This step can be triggered for several reasons. It can be the creation or update of a pull request by the developer or it is caused by the merge of a pull request on the main repository. Either way, the purpose of the step is the same. Validating if the quality of the entire repository matches our standards.

When executing this step, the build server will execute a variety of quality tests which basically are split up into two groups, automated tests and static code analyzers.

The group automated tests consists out of unit testing and functional testing. As an example you can think of tools as NUnit, PHPUnit or Behat. These tests are present to validate if the tested functionalities are still matching the expectations of the tests. They are mainly used for regression testing, which boils down to the question of “does my change do what I expect and does it not break any other functionality”.

Static code analyzers consist out of tools that generate code metrics, check coding violations. As an addition to scripting languages, linting tools like PHPLint will check if the code can be executed at all. These kind of tools do not aim on functionality, but focus on code quality itself. Is your code consistent in indentation, do you consequently use the same naming conventions or do you have a lot of duplicate code in your repository.

PACKAGING If the continuous integration step succeeds we move over to the next step, packaging. The purpose of this step is simply to create a single deliverable which can install itself onto servers.

Within Coolblue we can differentiate two types of packages. For Linux systems we use rpm packages and the RedHat package manager. Windows systems will be packaged into NuGet packages and deployed via Octopus Deploy.

We deliberately have chosen to create packages that are close to the operating system, which makes life a bit easier. For example, by choosing for the RedHat package manager we chose a well known process. Known to developers and system administrators since they all have more than basic knowledge of the yum command. But also a known process for the distribution of packages. As a RedHat user you know how repositories work, how they combine with yum and its process.

There a lot of useful tools in the open source community like Capistrano that could help with distribution of artifacts to a production environment. All of those tools have their own pros and cons. For us it felt that we would add a lot of unnecessary complexity to our pipeline and process.

Packaging and delivering .NET services is something different. There is no problem to package .NET applications into a Windows native package format, but hooking into a generic package management on Windows is not possible. So, we tackled this problem a bit differently.

.NET applications will be packaged into the NuGet package format. NuGet being an open source package manager for Windows environments. The build packages then will be distributed in the later steps. The generation and deployment of NuGet packages is worth a whole article on its own which we will publish in the future.

CONTINUOUS DELIVERY We have created a package containing our inspected code repository, now it is time to get it actually on a server so it actually can be used. This third step of the build pipeline will publish to development and accept servers.

Before I start to explain what we do exactly in this step it is wise to get a clear vision how continuous delivery differs from continuous deployment. The difference between the two is small, but significant.

Continuous delivery are all automated deployments of packages to any except production. Continuous deployment describes the automated deployment of a package to production. So during this step our goal is to get the generated package on different servers so the deliverable can be checked and is available for other team members. The deliveries done by this step might differ per project. For example, some projects might have an acceptance environment we need to publish to, others might not.

CONTINUOUS DEPLOYMENT With the continuous deployment step we reach the end of our deployment pipeline. In this step we actually deploy the application onto a production server. For Linux environments that is adding the package to our internal repository server. Windows environments will push and install the package onto the production nodes.

For us this step currently isn’t automatically triggered. A developer manually needs to trigger this build step to get his changes onto production servers. This isn’t something we want. but is necessary due to the lack of automated post-deployment tests.

In post deployment tests we want to check if the deployment went successful, something we currently do manually. For example by checking if the homepage returns a HTTP status code of 200. We want to check if we are still able to add a product to the shopping cart. Is our checkout process still available. These are the most viable tests we have after an deploy since they are critical to our business.

When we automate these post deployments tests and are able to do an instant revert of the deployment we will automate the trigger to have true continuous deployment.

In a high overview this article describes our continuous deployment process. A process which is working fine for now, but we are still working on to optimize. Objectives on our radar are for example the automated post deployment tests and implementing canary deployment.

http://devblog.coolblue.nl/tech/continuous-deployment-of-our-software/

这个直接问 IBM 公司的技术支持就行。这个东西价格不低，用的人少。

Kubernetes、Docker Swarm、Mesos 作为时下流行的容器框架受到了广大开源爱好者和企业的关注。面对用户需求不断的升级和自身产品不断的改进更新，其功能愈发趋于完善，迭代版本也不断的发布。因为篇幅过长，分上下两篇推送，本文为下篇。

1. 弹性缩放和理想状态的调整

Kubernetes 通过 RC 设定 Pods 数量，其管理器可以自动保持和维持以确保服务的高可用性。Kubernetes Master 会时刻检查集群状态，对与既定规则不符的 pod 进行调整。如，既定当前 3 份 pods 一簇运行当前服务，其中一个 pod 因为某些原因失败或停止，kubernetes 管理器会尝试指定的其它 worker 节点上新规重启 pod。针对实时使用的资源大小也会监控，调整并分配最佳数量（在预定上下限内）。

Docker Swarm 对于每项服务，你都可以明确想要运行的任务数，当你增加或减少任务数时，Swarm 管理器可自动增加或删除任务，以保持理想状态。其管理节点持续对集群状态进行监控，并对实际状态和你明确的理想状态之间的差异进行调整。例如，当你创建一个服务来运行一个容器的 10 个副本，托管其中两个副本的工作机崩溃时，管理器将创建两个新的副本，代替之前崩溃的两个。另外，管理器会将新的副本分配给正在运行且可用的工作机。

Mesos 通过 Marathon 管控。Mesos master 给 slave 节点分配任务，如果需要调整，它就会通知 marathon。Mesos slave 负责运行容器，并且报告当前节点的资源使用情况。

1. 网络方面

Kubernetes 官方支持 Flannel、Calico、Romana、Contiv 等众多组网方案。保证每一个 pod 都拥有一个扁平化，共享网络空间的 IP，通过该 IP，pod 就可以跨网络和其它物理机或 pod 进行通信。一个 pod 一个 IP 创建了一个干净，反向兼容的模型。在该模型中，从端口分配、网络、域名解析、服务发现、负载均衡、应用配置和迁移等角度，pod 都能被看成虚拟机和物理机；

Docker Swarm 使用多主机网络，保证可以针对用户的服务指定一个覆盖网。Swarm 管理器初始化或更新应用时，它会自动将地址分配给覆盖网上的容器；

Mesos 在 1.0.0 保证了对容器网格标准 CNI 的支持，CNI 标准是多家网络厂商参与制定的容器网络标准，Mesos 兼容了 CNI 标准，相当于间接的支持了 VxLAN、DC/OS overlay、Calico、Weave、Flannel 等多种网络技术。这是继容器 IP 功能后，Mesos 的又一重要的网络功能。

1. 服务发现和负载均衡

Kubernetes 通过 Services 定义了由容器所发布的可被发现的服务/端口，以及外部代理通信。服务会映射端口到外部可访问的端口，而所映射的端口是跨多个节点的 Pod 内运行的容器的端口。也可利用 nginx-ingress 等外部负载均衡器。其服务内部均衡使用 kube-proxy。

Docker Swarm 管理节点给 Swarm 集群上的每项服务分配一个唯一的 DNS 名称以及负载均衡的运行容器。可通过嵌入 Swarm 的 DNS 服务器对集群上运行的各个容器进行查询。

Mesos 则使用 Mesos-DNS。Mesos 上的应用和服务可以通过 DNS 的方式来发现对方。Mesos-DNS 的特点是轻量、无状态，易于部署和维护。

1. 安全方面

Kubernetes 引入了 RBAC（基于 Role 的访问管理控制）功能，该实现源于 OpenShift 项目。（该 RBAC 系统建立于 Kubernetes 资源之上，可以让角色、权限和关系动态作用于 first-class 的 API 交互，将之前 Kubernetes 版本的 authZ 设施中的静态平面文件放置于其后面。该 RBAC 功能被添加进了 Kubernetes 1.3 中，简化了针对不同企业群体、团队或者会计制度的关于多租户环境中的创建情况。）

Docker Swarm 通过各个节点强制 TLS 相互授权和加密，从而确保自身与其他所有节点之间的通讯安全。可选择使用自签的根证书或自定义根 CA 证书。

Mesos 在 1.0.0 中通过提供更细粒度的授权验证机制对此作出了响应。首先，在 1.0.0 中，Mesos 的所有敏感数据入口都是经过 SSL/TLS 加密的；其次，Mesos 管理员现在可以通过配置 ACLs 来限制用户只能在 WebUI/API 看到自己的任务了，而这就是企业用户的 must-have 要求；最后，Mesos 也提供了完善的 authorizer 接口，企业用户可以通过该接口添加自己特有的安全策略。

1. 滚动升级方面

三者都保持相同的功能，即升级时，可以将新老版本服务共存，逐步减少老版本数量增加新版本数量，直至全部更新。如果出错，可以回退到升级前的既定版本。

1. GPU 支持

三者都对 NVIDA GPU 有一定程度的支持，可是在调度的时候将 NVIDA GPU 作为资源进行调度。

1. 社区优势和合作方面

Kubernets 基于 Google 数十年运行大规模容器的经验，RedHat 多年部署和管理企业中的开源软件的经验，CoreOS 的敏捷开发经验和很多其他组织和社区成员的优势。亦有全球级大技术公司的支持，比如微软、华为等。

Docker Swarm 属于 Docker 自身设计，研发和维护；

Mesos 作为老牌技术也有着广泛的支持团队，如 IBM，Microsoft，Nvidia。其中，IBM 已经成为紧随 Mesosphere 之后的第二大 Mesos 代码贡献厂商，未来 IBM 会在 Mesos 的 optimistic offers，资源分配优化和兼容 POWER 平台方面投入力量。同时，Mesos 也推出了 Mesos 运行在 Micrisoft 上的试验功能。

1. 其他

Kubernetes 在 v1.3 中增加了 vsphere_volume 卷管理。通过结构体 VSphereConfig 可以看出来，kubernetes 的 vsphere 卷管理插件可以直接连接到 VMware vCenter 上。如果 kubernetes 是部署在 vsphere 上面的虚拟机里面，那么可以通过给虚拟机挂载硬盘的方式来给 kubernetes 添加卷。

Mesos 近期内在做的有关容器的开发。第一个是 Nested Container，当我们跑容器的时候，可以在容器里面将它分割成更小的容器。当大容器里面可以管理一定资源 boundary 的时候，重新再贴上更小的容器，这个对于跑 CI/CD、Jenkins 在 Mesos 上时很有用，每一个 Jenkins 都可以有自己的一个资源上限，它要跑十个 CI job，Mesos 就把已经有的资源给它们，但是它们确保不会跑出 Mesos 给的资源上限。

VM support 就是 Mesos 可以不跑容器，直接跑 VM，对于比较传统的一些 IT 企业来说，他们还没有办法从 OpenStack 或者从 VM 里面直接跳到容器里面，所以这是非常重要的一个功能。

现实中，的确遇到过很多这样的事情。

公司招人的时候，没遇到合适的候选人；当有不错的人选想要换工作的时候，公司有没名额了。

要我么？我去给你帮工

如果多个 svn 库共用一个 apache 配置，其他的库没问题，就这个库有问题。那么很可能还是数据问题。

你的 svn 是本机搭建的？

公司肯定是赚的，只不过看老板是否大方，赚多赚少的问题

没待过，不是很清楚，难道配置管理不算人头里的？？上次有个银行外包也是配置管理能给到 30

银行外包人头费很贵的。这个怎么给真么少？何况还要出差

你本地有没有这个路径？F:\svn_full_backup\2016\5\24\test

如果没有就建好，如果连 F 盘都没有，就修改下脚本，改下路径

​ 如何能从 6/70W 跨跃百万年薪那个坎？— By OfferCome

最近和一个年轻候选人探讨他的职业瓶颈时，忽然想到的。 一、背景： 毕业 3 年硕士；BAT+ 某著名创业团队，绩效前 10%；北航档学校本硕，成绩 10%。 拿了一圈 offer，基本都停留在 70W 左右（含期权股票）的水平，差不多是 3~40K*15、16+10~20W 股票。

二、整个行业： 今天看，资质中上的童鞋，通过自己的努力，6、70W 基本都是可达到的目标，只是时间的早晚。A\B 家的 7 都能到这个数字，很多上市公司、C 轮公司也有大把这种职位。 但不考虑 E 租宝这种高风险创业团队，6\70W 又是绝大部分人的坎，如何能迈入下一个台阶，进入百万年薪那个梯队？

三、建议： 我们认为有三种方法可能会迈过这个坎。

1、技术大拿： 能解决常规骨干解决不了的问题——这种方法，看天分。

这种分为两类讨论，一类是偏应用层的岗位，一类是偏算法等的岗位。 1）、偏应用型、业务型开发的团队 纯靠技术，升到百万年薪，很难。例如 Java、Android、iOS、PHP、前端等。做这类开发的， 纯靠技术上百万的，凤毛麟角。就像 B 家，地图、贴吧等团队里面 Android、iOS 想升 T7\8\9，很难，原因大家都懂。

2）、算法等团队里 靠技术，拿到百万年薪会常见一些，就像 A 家的妈妈，8 不少，9 也在变多。凤巢、网盟等的算法高 T 比例也远多于 java 的高 T 比例，原因大家也都懂。 ——再次强调下，走这条路线看天分。

3）、举个技术很难，但是收益低的反例 这里有个反例是 C 语言开发，是一个性价比、投入产出收益低的职业。 主要原因是： 1）软件开发领域在近年的发展突飞猛进，从更高级的语言，到更完善的工具链，从更活跃的社区，到越来越成熟的各种工程方案，加上各类各层次 “云” 服务的出现，以及硬件性能的倍增，都让需要 C 语言才能干的事情越来越少； 2）目前的互联网，99% 的开发需求还是集中在业务逻辑的实现，更为底层的应用还是极少数的。 导致的结果是：C 语言在各种领域里的开发，从入门到精通的线路很陡峭，而必须要用的地方却很少。 因此除了 BAT，创业团队中除了云平台、头条这种，剩下的公司都用 Java、PHP 等，集中在业务逻辑的实现。哪怕是大公司，底层工程师的团队也不大，导致在整个行业里，这样的职位占比越来越小。 结果就是，没几家可去，不太谈得上价钱……

2、带团队拼业务： 对于偏应用型、业务型开发的人，怎么办？带团队拼。 我能带着 2、30 个人，抗下个几百万日活 APP 的所有事情，老板你不用再操心进度、闪退什么的了； 我能带 3、40 人，负责公司 CRM、客服系统等所有事情，老板你不用再操心任何事情了，甚至从招人、留人这种事我自己全盘搞定…… OK，行了，7 位数拿走，这摊事交给你了。 至于说你能负责整个交易、支付 balala，公司交易额几百亿，来，这几百万是你的。

——这条路拼什么？拼综合能力，拼管理。能赚 6、70W 的人，如果愿意转、愿意学，只要不是太闷太偏激，一般都可以做到。 ——其他注意的：除非到了 BAT 总监这种高层，否则，作为中层，一定不要脱离一线。 现如今，整个互联网行业都是扁平化的，最需要的是：能带着一票兄弟姐妹熬夜发布失败回滚，然后在那吭哧吭哧找 Bug，然后再发布成功，带着兄弟姐妹撸串谈心的。 中层，纯管理的坑，少。 今天 B 家的 2A\B 很难找坑，但是 7\8 还是容易多了，甚至 3A 都比 2A 好找。因为总有人需要 3A，但对于中层这档来说，我为什么不找个 P6、7 而找个 2A 呢？

3、眼光准，选对行业、团队： 去哪儿上次发财报的时，CC 在朋友圈说，他最骄傲的事情是在去哪儿实现了 1500 个彻底财务自由的家庭。这个是真的，问问去哪儿的 14 级以上的，或者工号 1、2K 号的，都知道。这一年，交税要交几百万，上千万的，比比皆是。 我们从 10 年起跟去哪儿合作，看着很多人升了 13、14、15……买了大房子，最近在盘算明年拿完股票后是创业还是退休。 至于 A 家，就不用说了。 这种，一般会带来 3、50%~N 倍的溢价。

——这条路拼什么？ 逻辑很简单，选个 “大的行业”&“刚开始互联网化的”&“行业第一二名”，一头扎进去，可能中间需要换条船，但是之前的经验肯定会带来溢价（例如，早些年电商、团购、O2O、金融等各个行业内公司轮番相互抢人。）。 然后呢？然后，拼 5~10 年，等着自由。没了。

入行必读：互联网行业薪酬等级

拉勾导读：互联网行业猎头分享互联网行业的的薪酬情况，从事互联网行业的小伙伴们快来看看自己的薪酬水平属于哪个级别！

今年的互联网、IT 市场的行情如何？我们 OfferCome 主要集中做北京的互联网市场，在这方面的数据池子很大，敢对自己写的负责。因此我仅讨论北京 IT 的行情，不敢造次上广川的。

下面依次介绍应届生、社招、部分热门职业的薪水情况。 一、应届生 先说点轻松、简单、透明的应届生 offer 情况。

记得我 07 年刚做猎头的时候，完美给应届生开了 20w 的 offer，开启了互联网应届生 20W offer 的时代。当时各大外企给应届生普遍也就 6、7K，记忆中 google 普通 offer 也只有 18W，当时的亚运村房价才 1w 多，回龙观还 7K。

现在呢？热门的有拿美国 FB、Google 10w 刀的 offer，完美、网易游戏 40W 的 offer。你拿个 30w 的 offer，只能说是个好 offer，都不好意思贴到论坛显摆。

至于说 20w 的 offer，百度去年 13~14*14.6 的 offer，应该发了有 1、2 千个？阿里给本科生都开到 15K*15 了。

1、一线互联网公司：

BAT，腾讯的起薪还是一如既往地低，不过考虑到加薪的速度和年终奖的月份，实际上，这三家第二年都差不多能到 20W（腾讯的特指硕士）。

2、二线互联网公司：

稍主流些的二线互联网公司，给应届生中较靠前的一批（能拿到一线互联网公司 offer 的那批人），一般都是 20W+，例如 360、去哪儿、美团、有道、搜狗等。据说 58、赶集给部分应届生也可以到这个数字，这个没有太多考证。

一般来说，对于有议价能力的那批应届生，你们拿着 BAT 的 offer，然后去 360、去哪儿、有道等谈职业方向、产品、薪水和户口，然后呆满三年再看情况是否跳，是个比较理想的道路。

否则，你去 BAT，一年招上千人，你很难选择自己想要做的产品、技术方向，户口一般也轮不到你。至于说成长环境？这些公司的核心部门，并不比一线的差。

部分传统老牌互联网公司。。。我就不说哪家了，应届生薪水堪忧阿，都快跟华为一个水平了。

二、社招

考虑到工作 5 年以上的人，薪水差距拉的已经很大了，因此在此只讨论工作 3~5 年的码农行情，5 年以上的，我们可以私聊。

我们 OfferCome 一般会把候选人的薪水分成 15~20W、25W 左右、30W 左右、40W+ 这几档。

1、15~20W：

即月薪 10~13*15 个月，三线互联网公司普通员工水平。二线公司的普通员工一般会卡到上限，或超出。

比如说三线公司搜房网（论财务数据，搜房可以算二线公司了，只是搜房不重视技术，因此可算三线团队）的普通技术员工，一般都在 15W 左右徘徊。

准二线的 58、赶集，他们的普通员工薪水基本都到或者超过 20W 的上限了。

这批童鞋所处环境的特点是：非热门语言（例如不是 android、IOS、PHP 等），甚至过时语言（例如某些公司还在用.net、C＃等），所在公司对于技术重视程度一般，仅限于做点访问量不大的后台或者交互、动画效果要求不高的前台页面。

对于这批童鞋来说，最好是早点转个较为主流的语言，或者转个公司重视技术的地方。

稍微热门些的行业，例如视频、电商，就算是二线公司，薪水都会超过 20W，例如同为二线的奇艺、艺龙、当当等，她们的普通技术员工，早过 20W 的上限了。

2、25W：

25W，就是月薪 15、16K*15、16 个月左右。

年薪，你现在应该在哪工作呢？

如果你不是在 BAT 中工作 1、2 年，而是工作了 3、5 年，那么你现在应该是一家二线互联网公司中较为主力的员工。

你肯定比普通员工强多了，你独立干活没问题了，你平时还可以帮助其他员工解决一些常见的技术难题，你在努力争取做 teamleader 或者部门的技术核心。

对于没到这个数字的童鞋，不管你之前什么背景，只要你肯努力，肯加班，不管你在二线还是三线互联网公司，你努力干 3 年都肯定可以拿到这个数字。

25W，社招的门槛。25W，对于社招的，有工作经验人士来说，这也算是一个槛。为什么？因为广大的互联网公司，对于有 3、5 年工作经验的，一般也不招 25W 以下的（除去部分不受重视的岗位外，或刚工作 1、2 年的人外）。

比如百度，现在很多部门社招一般都只招 T5 以上的，动辄就是 20K+ 的 offer 了。就算是不以技术起家的新浪，现在通过猎头招人，一般也都是招 3 级以上的员工，起点就是 15K 左右了。

当然，在部分热门职业中，可能你不管在哪家干一两年都有这个数字了，这个我们且按下，后面再讲。

3、30W：

20K*15，恭喜你，你老板舍得给你开 2W 一个月，那代表你对你们部门或者你们 team 是比较重要的人士了。 你一般是二三线公司的某个部门技术骨干了，或者在一线公司里面某个 team 的重要员工了。

你可能是百度 T5 的角色，你可能是淘宝的 P6 了（当然，如果你在淘宝，你还得算算你股票值多少钱，否则贵司光靠薪水没法比拼 BT 了），你可能在爱奇艺、优酷做个中级工程师了。

当然，就算你 30W，你也可能还是百度的 T4。（话说，百度亲们，谁能帮忙解释下你们现在的薪资体系吗？我们猎头看的云里雾里的，为什么以前 T5 都到不了 20K，现在 T4 都 20K 了，让我们挖人的时候无法适从阿，根本无法从级别判断你们的薪水。你们在搞啥子哟。。。。。）

4、40W：

嗯，月薪 25、30K？或者 20K+ 股票？一般老板不会随便给一个普通员工开这个薪水了，给你开这个薪水，你肯定是有你的过人之处。

如果在二线互联网公司，给你开这个薪水，一般担任以下角色的位子：你可能还不是部门整体的架构师，但在某个模块的工作中，算是技术的较权威的负责人。比如，后台存储相关的开发你是技术核心，或者数据库开发相关的工作有难题了都找你，又或者你是搜索某块的技术大拿。

如果做的是略微边缘化一些的职业，比如说测试、前端开发、运维，那你可能是整个公司层面，在这个领域都较为受重视的技术骨干之一。反正，你们在公司内的地位应该不错。

如果你在一线互联网公司，那你应该是 team 的最核心的骨干之一了，或者是类似 TL 的角色了。你是百度的 T5+、T6，你是项目经理？你在腾讯该是 T3.1 了？

反正，恭喜你们，你们已经进入了整个互联网的骨干行列，我相信，拿这个收入的人，大家应该都很聪明、勤奋、好学，互联网的道路对大家来说才刚刚开始。

对于你们来说，40W 只是个开始，你们的路才刚开始，只要你们够努力，还可以升 T6、T7、T8，M2，你们还可以跳去二线互联网公司做整个部门、整个公司的架构师，年薪百万可能有些遥远，但是只要你们不放弃努力，7、80W 还是不太远的（实际也就是 4W 月薪 + 股票而已，莫急，肯定能到）。

5、60W，1、200W 的人？

再往上？再往上走的那个层次的人我就不写了。咱们可以微博互粉一下，有空出来坐坐喝喝茶私聊。谈跳槽太俗了，你们三年也不跳一次，一跳就要呆三年，大家可以聊聊行业、聊聊各个公司的战略、人事变动，为你未来的发展谈谈看法，只谈风月，不谈跳槽。

三、热门的行业

准确地说，现在除了.net、c＃等过时的技术之外，别的都热门。什么大数据开发、广告计算、搜索啥的就不用说了，你们只要跳，我就敢要。

1、特别的例子

举几个比较特别的例子吧，就是跟算法、搜索不同的，求职门槛不高的，不需要算法好等要求的职业：

PHP：

百度招 C、java、PM、数据挖掘等，都很挑剔。要看教育背景、工作经历一系列。但是百度招 PHP 的时候还看教育背景吗？大专的 PHP 百度要不要？呵呵……

最普通的 PHP，工作 3 年左右，没有在一线、二线互联网公司呆过的，能力中规中矩，能独立干活，但不能解决技术难题的。现在的薪水是多少呢？起点一般是 15k*15 的水平，运气好一些的 17、18K 也不难。

稍微好点的 PHP，3 年经验，能力不错的，在百度等呆过 1、2 年的，学校也还不错的，20K 很稀松了。

这个没办法，跟百度、新浪、360 等大范围使用 PHP 有关，也跟众多创业团队使用 PHP 有关，需求大，人少，没辙。。。

Android、IOS：

这也不用说了，基本跟 PHP 差不多。今年还有一个小爆发的趋势。

这是我们 OfferCome 的起家行业，论这几年移动互联网行业的变迁，没有比我们更为熟悉的了。具体的原因，我们下一节仔细分析下这三年，移动互联网行业开发人员的变迁情况，大家可以拿移动互联网做个很典型的例子。

Java：

之前也纳闷，java 为什么稀缺？北京大把的 java！IBM、中软、亚信、东软，谁家不会 java？

后来发现，哦，互联网公司要求的 java 还不太一样，技术难度的要求还是蛮高的，之前给运营商、银行做项目的还真不太合适互联网。

嗯，那我们老老实实去互联网找吧，结果很憔悴地发现，除了阿里系、网易、百度的商搜、人人的一部分，别的没啥可挖的。然后京东又转 java 了，给本来就不太多的供给也造成了压力。

So，我们拿着 20~25K*16 的薪水想挖 3、5 年经验靠谱的 java 工程师，发现找不见人。

北京互联网领域，有个问题是，开发语言较为分散，PHP、java、C 是三个常用的，然后还有在用.net、C＃、python 等的，造成本来就不多的互联网从业者，还被分割成了若干个平台，极度地阻碍了人员流动，抬高了人员成本。

2、热门的行业

行业的热门一般是跟所在行业的垄断程度、发展速度、从业公司数量有关，目前较为热门的有电商、视频、搜索等。

赞美。不错的经验

后悔啥？？？