ELK=Elasticsearch(数据库)+Logstash(Log收集处理)+Kibana(展示平台)
对于这几个软件的特性和优势在这里就不再赘述了。可以参考各种资料和说明。
以前一直觉得ELK做日志收集分析有点太重量级，占用资源过大。最近对Elasticsearch进行了一些了解，感觉有很多优秀的特性值得采用。于是重新开始安装这套经典的重量级的开源日志收集分析平台。

对于ELK的安装在官网都有下载
这里只说几个要注意的地方
1、E和L需要JAVA环境，而且对版本号有依赖。
2、Elasticsearch不能以root权限运行。请自行建立非root账户
3、Kibana的rpm包安装完以后在/opt目录下。
4、Elasticsearch想创建pid文件运行（我用monit做监控用）请自行-f /tmp/es.pid
5、Logstash的配置文件需要自行建立 运行命令是 Logstash agent -f 配置文件路径

下面着重讲一下如何用Logstash对nginx的日志文件进行处理和入库Elasticsearch

首先在nginx的配置文件里对log-format进行配置
log_format access '$http_host $server_addr $remote_addr [$time_local] "$request" ' '$request_body $status $body_bytes_sent "$http_referer" "$http_user_agent" ' '$request_time $upstream_response_time';
这里包含 访问域名、服务器IP、来源IP、时间（带时区）、请求动词、请求体、返回值、请求体字节数、来源referer、用户UA、请求时间、后端处理时间（PHP处理时间）

tms.im 10.70.29.98 58.21.16.54 [26/Jun/2016:16:39:28 +0800] “GET /favicon.png HTTP/1.1” - 404 191 “http://tms.im/index.php” “Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36” 0.000 -

以上是log示例，因为是静态文件 所以后端处理返回时间是0
新建一个logstash的配置文件nginx.conf

input {
   file {
     type => "nginx-access"
     path => "/data/wwwlogs/access_nginx.log"
   }
}
filter {
   grok {
        match => {
            "message"=>"%{IPORHOST:domain} %{IP:route_ip} %{IP:real_ip} \[%{HTTPDATE:timestamp}\] \"%    {WORD:http_verb} %{URIPATH:baseurl}(?:\?%{NOTSPACE:request}|) HTTP/%{NUMBER:http_version}\" (?:-|%    {NOTSPACE:request}) %{NUMBER:http_status_code} (?:%{NUMBER:bytes_read}|-) %{QS:referrer} %{QS:agent} %    {NUMBER:time_duration:float} (?:%{NUMBER:time_backend_response:float}|-)"
        }
    }
}
output {
 elasticsearch {
    hosts => "127.0.0.1"
  }
}

其中需要注意的是grok的match段，网上查到的资料大都是直接输入grok表达式，而这种匹配已经被弃用，请使用如上的match段进行grok匹配。

这里grok匹配推荐一个网站可以在线进行grok表达式测试
http://grokdebug.herokuapp.com/
然后启动Logstash（之前已经启动了elasticsearch和kibana）

/ELK/logstash/bin/logstash -f /ELK/logstash/nginx.conf

这样Logstash就配置完成了。进入kibana的管理界面。第一次进入需要进行mapping，点确定完成后即可看到数据。

然后就可以建立Dashboard做各种统计分析了。

绝大多数的互联网公司是扁平化型组织，即去中心化。比如从CEO到Team Leader再到工程师只有3个层级。CEO定下目标，分别下放权力，交给每个层级分别完成细节目标，CEO只需关注他关注的核心事项和目标即可。

##创业公司的组织架构

一家公司从0到1，人员也是由两三个人一点点成长出来的。对于技术团队来讲，差不多开始时就是三五个人，七八条枪。
公司刚刚创业始，可能研发就两三个人，基本上几个人协同战斗，有人来做后端，有人来做客户端，有人来做前端，几个人齐头并进，不耽误时间。

这种最简单的作坊型技术小组，靠的是每个人的激情信息还有自我管理，这种团队的效率也是最高的。

这时候CEO关注的只是是产品进度，如果是技术型的人，可以和大家一起编码，或Review，和大家一起战斗。

比如Youtube的陈士骏，他和另一个创始人日以继日的开发；早期雅虎的杨致远两个人从做静态页面开始干；豆瓣的杨勃一个人在咖啡厅开发网站的第一个版本。还有很多很多故事，基本是一两个人合作开发，技术好的说着算，随着产品的用户数和功能变多，这时需要更多的技术伙伴加入。

##微型技术团队的组织架构

创业公司的技术团队一般是主管（Team Leader）+工程师两层。主管一般是水平好的工程师担任，当然也可能是CEO信任的人。由他负责项目管理和推进，并向CEO汇报。

比如我在赶集网的时候，最初只有3个技术，我是其中一个，一个人负责运维，我负责编码开发，另一个人是兼职开发。

对我们几个人来讲，我周末也会到公司来，一个人能够完成一个系统的全部开发，而不用有人来指挥。

这种组织异常简单，但最主要的是招到有内驱力的人。什么是内驱力?就对自己有要求，对时间，对质量负责。基本上这种组织并没有什么管理，只是向前推进。

在那个时代，我们3个人与竞争对手58同城十几个技术团队PK。

综合以上之实例，其实10人以内的技术团队，并不存在什么管理，全凭大家互相协作。自主自发自觉，干活随身带鸡血，一块向一个目标跑：上线。

##小型技术团队的组织架构
10人到20人左右的团队。这个时候产品的运营流量已有了一定规模，需要按不同的系统区分。比如网站、APP。

此时，按不同端分开并委托一位负责人，可以称为技术经理，由他向技术负责人汇报。

各位可以看到，组织结构按PC和移动，按不同的设备端，对开发小伙伴做了一个区分。引入了质量管理和测试小组，用来管理代码质量和发布流程，以及黑白盒测试。

##中型技术团队的组织架构

我把中型技术团队定位在20-40人左右。当然人数是方面，人员的能力也是一个考量范围。
这个时候的技术团队是要面对运营已经相对成熟的产品。拿电子商务公司为例，按业务系统进行分层。比如：

我们可以看到，此组织架构按照业务系统进行了重组，有前端网站，网站包括PC端产品，还有手机端H5网站和微信公众号，后端运营系统包括库存管理、财务管理等，合作伙伴包括代理分销、开放平台等系统，移动端研发部门包括iOS和Android平台，可能还包括不同的客户端版本。

在这里，大家可以看到组织形式已经按产品为核心分组，仍然为扁平型组织。即每个小组根据用户和运营之变化，快速做出决策，以便能够承受更多挑战的技术体系。

##大型技术团队的组织架构
大型技术团队的人数在500-1000人左右的规模。对于这么多研发人的团队来言，协作越来越困难，需要把每个业务拆分成不同的小团队，每个小团队各自迭代开发。

按照以上之组织结构，可以减少团队利益之争。CEO和CTO可根据业务需要拆除或新建一个产品研发Team。

转自21CTO

今天看到V2ex上面有人问 “touch6 值得入手吗？”，作为一个用了一年touch6的人就顺手回答了一下。这里也记录一下。
touch6 刚出就买了一个，说实话我觉得还是挺值的。首先我是安卓党，所以需要一个可以玩 APP 的 IOS 设备。买 IPhone 用不到电话功能也太贵，买 IPad 感觉太大了，最后买了 touch6 。用了快一年了，感受就是：
1 、轻，非常轻。带着很舒服。在路上听听歌看看电影玩玩游戏不会消耗手机的电量，很棒。
2 、只能接入 WIFI 上网是劣势也是优势。我把一部分只离线用的支付帐号放在上面了。感觉不怕被木马盗。心理上安心许多。
3 、手机上面装的软件大大减少了。能离线用或者只是 wifi 条件下才会用的软件只装在 touch 上。手机的续航时间大大增加。最多也就用来跑个聊天软件之类的。买 touch 的一大初衷也是为了分担手机电量。
4 、虽说 touch 不支持 GPS ，但是我还是用他来做一些健康管理。比如计步。记录睡眠状态。记录心率之类的。顺便安利 Heart Rate Pro 、 Sleep Cycle 、 Gyroscope 这几款健康管理软件。
5 、关于电池，我还真没觉得会很烂。至少我听歌的话连续放三四个小时也试过。用一半电吧。是外放。用耳机的话大概能连续听七八个小时。看视频玩游戏连续三四个小时不是问题。电池电量小是肯定的。但是 touch 用电也少。而且更好的一点是。充电特别快！特别快！特别快！重要的事情说三遍。大概半小时左右就充满了。所以还是很爽的。
6 、颜值高就不用说了。这小东西确实好看又方便携带。经常听歌的人表示随时带着。带个手机再带个 touch 完全没感觉重量增加。
7 、还有，拍照效果也还不错。暗光效果下比我的小米 4C 成像好的多。不得不说苹果的优化做的真无敌。所以我也经常用他来拍照。手机没电的时候也可以找个有 wifi 的地方应急用一下，上个聊天软件啥的。平时就是用来挂 QQ 微信小号了。
总之
对于IPhone用户来说，touch用途不大。
对于android用户来说，看你买touch的目的是什么。
对于追求大屏幕的人来说IPad更适合你。
对于用来当备机的人当然应该再买个手机，touch不适合你。
如果你只想买个用来玩的，方便携带的 IOS 设备，顺便可以分担手机电量。 touch6 是个很好的选择。

对国内外的生物信息学实验室，我做一个粗糙但很实用的分类：
一是开发、设计生物信息学方法、技术，构建生物信息学数据库；
二是利用别人的方法、技术和数据库、辅之以简单的程序设计，来研究自己关心的生物学问题。
三是二者结合，既做一些方法技术和数据库，也做一些纯生物学问题研究。第一类实验室的导师一般具有数学等非生物学背景。第二类实验室的导师一般具有生物学背景。
第三类实验室的导师可能具有生物学背景、也可能来自于数学、信息学等学科。第三类实验室一般都是从事生物信息学时间较长，无论生物学、数学、还是计算机科学方面知识积累都很丰富，所以一般也都很成功。第三类典型的例子是NCBI的Koonin实验室。

0级 (Level 0)：为建模、而建模（modeling for modeling’s sake）。简称：渣级。Shirley在博客里提到说“如果你记得功夫熊猫”，问题是我没记得这个，脑子里想的是《憨豆的黄金周》里那段nothing, nothing, nothing… 原博举的例子是，之前有人问：现在数据这么多，能建模的东西一大把，那我们该干点啥呢？Shirley就问：你想解决啥问题？答：建模的问题。这就像我坐电梯看见认识的研究生，说小伙最近忙啥呢？答：做水稻呢。继续问：具体研究的啥？不高兴了，诧异：研究水稻啊！然后给我解释了半天中国要研究水稻的必要性。我…兄弟我每天吃米饭还固定要研究水稻三遍呢。原文解释，这个回答是OK的，如果科学家仅仅将自己当成数学家、统计学家、计算机科学家、物理学家，或者像我这样用嘴巴研究水稻的吃货，因为在这些学者各自的领域里，确实有许多好的理论建模问题。但如果这些学者是认真对待生物信息学的研究，这个回答不OK。许多0级生物信息学家们从来不读或者不发表生物学期刊上的论文，也不参加生物学的会议，因此这个级别属于“未入门级”。根据人以类聚，物以群分的原则，0级生物信息学家们通常只阅读自己或者其他0级生物信息学家的论文，并且，并且引用也是自引或者被同级别的学者引用。因此这类研究就是浪费资源。

1级（Level 1）：给数据、能分析。简称：菜鸟级。这类研究一般是分析自己或者合作者实验室里未发表的数据，并试图获得新的生物学发现。相比与0级，这已经有很大的进步，并且是训练生物信息学者最好的途径之一。可以练习将已有的生物信息学技术来做出真正生物学发现的技巧，学习更多的生信技术和生物学知识，可以启发、衍生出2级和3级的好课题。评价1级科研的功底和水平要看数据有多复杂, 是否需要生信人员写一些程序和算法（而不是只用他人的工具），生信分析在整个研究中的有重要性 (最重要的假设发现是不是由生物信息分析出来的，文章中生信图表的个数)，实验与计算的结合程度 （实验与计算 环环相扣，而不是高通量实验数据获得完跟个生信分析就拉倒），以及研究中生物学的发现是不是真的有意思，等等。因此兄弟我的看法是，1级虽然是“入门级”，但非常非常重要，所有生信专业研究生的必经之路，非生信领域的学者或学生，能达到1级中已可算是高手，进阶到1级上那就是凤毛麟角了。

2级（Level 2）：想新招、玩数据。简称：肉鸟级。具有2级水准的生信研究有：1) 设计方法解决生物医学相关大数据分析中普适、定量的问题。比如咱生信课本里经典的用于双序列比对的Smith-Waterman算法等等；2) 设计算法来分析新的高通量技术所获得的数据，例如华大基因设计的用于二代测序短读段 (read) 映射到基因组上的SOAP系列工具，这就是典型的2级工作；3) 从各种公共数据中通过整合建立数据库或数据资源。这个太多了，生信领域各种专业、精心注释的数据库，都属于2级的研究。2级比1级高的地方，在于1级只能帮助一个实验室或者固定的、极有限的合作者，而2级的工作则可以帮助数百甚至数千的生物学家。2级的工作不必须发表在顶级的期刊上，时间会证明一切，比如分子进化领域的经典软件MEGA，每年几千的引用跟玩儿一样。这些方法并不见得必须要非常新，利用已有的统计或者计算方法来解决新的生物学问题已经足够保证其新颖性，但必须尽可能保证用户的友好性。开发者一般在发表之后还需要做非常非常多的工作，比如维护、升级，即使不在发表后续的论文。评价2级的生信研究工作不能数影响因子，但做的好却比较容易被领域认可（例如，华大基因发表NCS对咱搞生信的来说未必认可，但人家的SOAP系列做的肯定是专业水准的）。此外，2级的研究要做的好，生物信息学者一般需要专注于自己特定的方向，从而能够较好地了解领域内相关的、新的计算方法和实验技术。总体来说，国内生信专业的博士毕业，一般起码要做出2级下水平的工作，总得有点儿新玩意儿，不然想毕业几乎是不可能的。而对于非生信领域的学者，从1级进阶到2级几乎是不可能的，咱生信人的饭碗，不是想砸就能砸的了的。所以对于业余票友们来说，与其花精力试图进阶2级，还不如找专业学者合作更划算。

3级（Level 3）：玩数据、作发现。简称：顶级。3级的生信研究一般是整合公共的高通量数据，利用相当精致的方法来做出生物学发现。因此这样的工作一般是从数据开始，实验验证结束。这就需要生物信息学家具有非常扎实的生物学知识，并且能够自己提出有意思的生物学问题。生物信息学家可以领导一个生物学的项目，并且实验学的合作者能够相信预测的正确性以及意义，并乐意开展实验验证。这个级别的研究一般都需要实验验证，不然顶级的期刊不收。对这类工作的评价，主要是看生物学的问题是否有意思，数据整合和分析是否有足够的技巧和合理性，并且也可以根据杂志发表期刊的档次（影响因子）来判断。例如我在《环形RNA分子：论开挂在生命科学研究中的重要性》提到的工作，这是典型的3级研究。从2级进阶到3级很困难，兄弟我目前正在努力中。

X级（Level X）：玩科学、讲政治。简称：神级。在这个级别，生物信息学家要在巨型项目产生的海量数据的整合和模拟中发挥关键作用。做这个级别工作的生物信息学家一般具有良好的1级和2级的研究记录，并且在团队研究中要具有非凡的领导才能。这些工作一般都发表在顶级的期刊，并且引用极好，在研究过程中要注意协调方方面面。尽管有时生信对于这些论文的发表是重要的，但往往数据本身可能比方法更重要。例如期刊判断论文要依据其数据量的大小以及潜在的引用，而不是生信。此外，这类工作更多的是反映第一作者老板们的领导力以及在领域里的地位，而不是第一作者的技术能力和创造力。所以X级论文的第一作者们往往并不会得到足够的认可。因此，这些工作中的一作在独立研究之后，往往是必须建立科学的声誉，并且与之前X级工作无关。学者参加一些X级的生信研究无可厚非，因为这些项目的成员一般在各自领域都是顶级学者。但如果学者只开展或者只发表X级的工作，那就表明该学者在政治方面的关注已经超过科学了。兄弟我举例：典型的X级生信研究工作如艾瑞克•兰德 (Eric Lander) 领衔的人类基因组草图的公布《Initialsequencing and analysis of the human genome》。艾瑞克是第一作者也是共同通讯作者，因为这篇论文主要是他写的，所以数据也自然主要是他分析的。这篇论文影响深远，最重要的就是基本确定了基因组学这类超级项目的研究范式以及论文的书写格式，例如这类论文一般不带后续的实验验证，所以也是有争议。这也就是为什么国内老是讲华大在灌水的原因，第一，华大显然是在灌水；第二，这个灌水模式是老外发明的；第三，那你很容易就能明白，其实老外灌的更狠；第四，你老外自己定的游戏规则，你还玩不过华大，那你得懂“愿赌服输”这个道理。

Shirley总结，对于生物信息学者来说，一般从1级的研究开始，学习基本的生信技术；等到计算和生物学知识掌握差不多之后，可以尝试想2级和3级进阶，并且有可能也参与X级的研究。如果条件允许的话，一般有成就的生物信息学家的研究会从1级做到X级，不会专注某一个级别（所以搞生信研究不能挑食）。也有许多生信学者包括Shirley本人也在开始做实验并且产生实验数据，这样实验的内容要拿去跟实验学家的工作去比，而计算部分则可按照上述五个类别来评价。因此，当您再读基因组和生信的论文，可以带着“这是什么水平的生信工作”这个问题来阅读。尝试客观的评价生信工作，而不是数论文发表期刊的影响因子。

##简介

我们相信公平和透明的薪酬机制很有益于公司的长期健康发展。我们在设计薪酬体系时重点考虑了几个问题：

• 避免薪酬倒挂：很多公司，尤其是大的互联网公司在人才竞争激烈的年份给出较高的入职薪水，而老员工的薪水因为惯性没有相应提高，所以造成了新员工入职薪酬高于老员工的不公平现象。
• 消除薪酬谈判带来的不公：在招聘时，很多公司往往会根据候选人之前的薪酬以及他/她的期望值在可接受的范围内确定 offer。这样的方式事实上惩罚了之前薪酬偏低的人和不善于薪酬谈判的人，而有利于之前薪酬偏高或者善于薪酬谈判的人，造成了能力和贡献相似的人薪酬产生较大差别，也就导致了组织内部的不公平。所以我们决定从机制上保证给出的 offer 完全取决于我们自己对候选人的独立评判，与其他因素无关。做到这一点，自然也就不应有任何因素导致我们对 offer 进行调整，就可以把薪酬谈判从招聘中去掉。
• 简单透明：作为一个精简的创业公司，我们需要一个透明、自动化的机制来保证在薪酬这样的敏感问题上尽可能的公平。当人为因素越少，机制越透明时，大家就越不需要把注意力放在这些方面，日常运作也更简单高效。
• 保持灵活性，避免线性等级：专业领域的专家和承担管理角色的同事对团队都很重要，这需要在薪酬体系中体现。

##月薪的计算

每位同事的月薪由下面的公式得出：

Salary = Function × Experience + Impact + Choice + Adjustment

其中 Function 是不同职位类型的月薪基数， 会随公司发展的情况进行调整。当前各类型的基数如下：

以上是我们现有的职位类型，将来会根据需要增加新的类型。

Experience 是不同经验和能力等级。对于新加入的成员这个等级会根据面试情况确定。对于在职的同事，会根据实际工作情况进行定期 review 和调整。这是一个团队内部的标准，和外部的通常标准或其他公司的职称标准完全无关。Experience 所对应的数值如下表所示：

Impact 指的是在团队中的影响力和贡献，对应的数值如下图所示：

由于在面试中无法衡量将来在团队中的实际贡献，我们在新的 offer 中通常会把 impact 定为 I0 留待将来调整。

Choice 除联合创始人月薪的 Choice 部分为 0 外，其他同事在入职时默认 Choice 部分为月薪其他部分的 10%。我们会按期权激励计划授予每位同事期权。新同事在入职的第二个月底前可以在期权和月薪间做一个倾向性选择。选择期权的同事可以放弃月薪的 Choice 部分而在原定期权基础上多获得 20% 的期权。

Adjustment 这是一个对所有人固定的调整，目前为 1000 元。

##例子

假设某个 function 的基数是 13000，那么这个 function 的 experience level 为 E3、impact level 为 I1 的同事，她的 Function × Experience + Impact 部分就是 13000 × 1.4 + 5000 = 23200。如果她选择更多期权，那么她的月薪就是 23200 + 1000 = 24200。如果她选择更多月薪，那么她的月薪就是 23200 × 110% + 1000 = 26520。

##奖金

目前我们周期性的奖金是每年的年终奖。年终奖的金额是浮动的，规则详见 工作的评价和反馈机制。

##结语

以上的机制借鉴了 Buffer 的 Open Salaries，具体的公式按照我们的情况做了调整， 希望让每个人都能清楚自己薪酬的由来以及未来的空间，也让潜在的应聘者一目了然了解可能的薪酬范围。

所有同事的薪酬以及发给候选人的 offer 都严格遵照这个标准。我们有可能不定期地调整各类职位的基数以适应公司发展的不同阶段并保持竞争力。由于这样的调整是整体的，所以不会导致倒挂等问题。另外由于影响最大的因素是 function 和 experience，这个公式也保留了足够的灵活性。比如一个很资深并作为项目负责人的工程师薪酬完全可能达到或超过 VP 和 C-Level 级别的管理者。

任何制度都会经历在实践中完善的过程，我们会根据反馈在发展中不断地完善这个薪酬体系。

转自http://open.leancloud.cn/salary.html