运维工具真的很容易做吗

在从研发转到运维之前,我一直就觉得运维工具这东西,应该是相当简单的,但在我自己带领一个运维工具团队一年多后,完全颠覆了我自己以前对运维工具的认知,才真正明白了运维工具这东西要做好,对技术的要求其实是极高的。

之前之所以觉得运维工具简单,是因为从在线业务系统角度来看,运维工具访问量低,数据量也很小,完全看不到什么技术难点。

在带领一个运维工具团队一年多后,看到的是运维工具系统对技术的要求其实和在线业务系统只是角度不同而已,先看看运维工具系统主要承担的职责:
1. 运维操作的自动化;
2. 线上故障出现时救命操作的执行;

这两个职责决定了在运维工具系统设计时除了功能实现外需要考虑一些非功能特性:
1. 运维操作的自动化
自动化要真正做到,有一个核心的关键指标:成功率,可以想象下,如果一个自动化的运维操作的成功率只能做到60%,那对用的人来说体现出来就是10次操作失败4次,这种情况下多数会造成的结果就是用户就不用了,因为用户会觉得还不如手工操作来得快,因此运维操作要真正做到自动化,必须确保成功率,这点和在线业务系统更不一样,在线业务系统对单次操作的成功率的要求会远比运维工具系统低,而且在线业务为了确保操作的响应时间等,fail-fast是在线高可用系统的基本策略。
一个复杂的运维操作,例如应用扩容机器,和在线业务系统其实很像,也是要操作N个其他的系统,业务逻辑也很复杂,是一次巨复杂的分布式操作,要保障好成功率,就意味着在A调用B出现异常的时候,得决定后续的动作,有可能需要做重试、跳过(有些可能还需要在完成后再异步操作什么的)再等动作,因此运维工具系统在依赖出异常时的处理策略必须做的非常清楚,尽可能确保成功率。
从这点可以看到,设计运维工具系统时需要更加趋向保障单次操作的成功率上,在各种异常出现时需要有各种处理策略,这和设计大多数在线业务系统是完全不一样的。

2. 线上故障出现时救命操作的执行
线上故障出现后,通常会非常依赖运维工具系统来处理故障,例如监控、发布、切流量等等,而如果在故障出现的时候这些运维工具也出问题,那就悲剧了,记得我们在很早以前讨论系统的一个救命招怎么实现时,一开始谈到了好几个高大上的方案,但最后选择了一个极为土的方案,原因就是因为这是救命招,基本就是能不依赖就不要依赖任何其他东西。
按照这样的要求,运维工具系统中如果是对于线上故障出现时属于救命型的操作,必须确保绝对的稳定,不论是小的故障,还是大到机房的故障,救命操作的系统都得保证绝对的稳定。
而且通常来说,一个救命操作看似一个简单按钮,但背后对应的多数都是N套系统的联动,怎么保障这个看似简单的按钮完全的可信赖,背后是有大量的事情需要做的。

因此从对运维工具系统需要承担的职责分析来看,在技术上运维工具系统其实也是有相当高的要求的,怎么样能保障好成功率、救命操作简单按钮的绝对稳定可靠,是运维工具系统必须做到的。

顺带再说下规模的事,简单举一个例子是可能很多小一些的业务场景里很难碰到发布量本身会变得很大的状况,而在我们的场景里曾经多次碰到过发布系统本身支撑能力不够导致的各种临时找办法的状况,因此对于运维工具系统来说,同样也必须做到知道当前系统能够承受的压力范围,以及怎么水平扩展。

所以,小看了运维工具系统的同学们,包括从前的自己,请正视运维工具系统面临的技术挑战,有兴趣的同学欢迎一起加盟来挑战!

最后,再次推荐下6年前黄易山讲在FB时的工程管理心得中很重要的一句话:Tools Are Top Priority,文章请Tools Are Top Priority

=============================
欢迎关注微信公众号:hellojavacases

关于此微信号:
分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test,以及和大家一起讨论一些Java问题或场景,这里只有Java细节的分享,没有大道理、大架构和大框架。

公众号上发布的消息都存放在http://hellojava.info上。

打造高可用的系统

两年前曾经写过一篇《构建高可用系统的常用招数》,主要是从软件设计的角度来阐述,而自从自己从研发转到运维后,这两年来看到了更多的故障,同时更深刻的感受是要打造一个高可用的系统,不是仅仅在软件设计、研发、测试阶段保障质量就ok的,但基本事实是随着业务的发展,系统的复杂度、新加入人员的冲击都会对质量带来极大的影响,因此故障基本是不可避免的,这个时候故障的恢复能力就非常重要,而故障的恢复能力不仅仅是一个简单的操作,其涵盖的一整套体系,从系统的架构到变更到故障出现后的响应机制。

在故障应对这个领域,很容易犯的一个错误就是在故障的根源定位上投入非常大的精力,这个领域投入固然是有价值的,但更多的情况会发现这个领域投入产出比很低,因为真心太难做了,之所以很容易投入更大的精力在故障的根源定位上,是因为在传统的思维上,我们都认为只有定位到了故障的根源才能制定相应的策略来修复故障,但事实上随着系统架构的演变,完全可以有更好的办法。

首先我们看看故障发生时影响的范围大小,通常来说是以下几种:
1. 单实例
单台机器出问题,可能是各种原因,例如硬件故障,或应用出了个偶发故障。
2. 单应用集群
系统里的单个应用集群全体出现故障,出现的故障的原因同样可能多种多样,网络、应用软件bug等,都有可能。
3. 多应用集群
系统里的多个应用集群都出现故障,不过话说其实单应用集群出故障也很容易导致这种现象。
4. 单机房
单个机房整体出现故障,这种通常来说是网络或机房(例如雷击,:))出现故障。
5. 单地域
单个地域出现问题,可能大家觉得很罕见,但事实上有多种因素可能会造成,例如运营商在某片的故障等。
6. 全局
所有应用集群都出故障了,对于没有多个机房、多个地域的而言,单机房的就算全局故障了。

上面的几种故障范围出现后,是否一定要先查出原因才能恢复故障呢,那是不一定的,恢复故障和修复故障完全是两个概念,就上面几种故障范围而言,在恢复故障上可以采用这样的方法:
1. 单实例
对于单实例故障的快速恢复,可以通过改造为集群方式,对于无状态的比较容易搞定,集群+七层健康检查基本就非常有效了,可以做到在出问题时自动应对;
对于有状态的,比较复杂一点,通常需要做主备,或类似paxos的一主多备等结构来做到单个实例出问题时的自动应对。
因此通常来说,单实例的故障是完全不应该影响到业务的。
2. 单应用集群
对于单应用集群整体故障的现象,如果是非关键路径的应用,可通过自动降级或手工降级来快速恢复故障;
如为关键路径的应用,应用部署在多个机房,并且只有一个机房的有问题,那么可以通过快速的切掉这个机房的流量来恢复故障。
3. 多应用集群
和单应用集群采用同样的方法。
4. 单机房
对于单个机房出故障,如系统是多个机房部署的,那么可以采用切掉这个机房的流量来快速恢复故障,这要求系统部署在多个机房,并且具备快速切换能力。
5. 单地域
对于单地域出故障的情况,如系统能做到异地多点部署,那么同样可以采用切掉机房流量来快速恢复故障。
6. 全局
如为全局出故障,那基本上只能靠定位故障,然后来看看怎么快速恢复。

从上面这个简单的阐述可以看到,除了全局故障外,其他类型的故障在系统架构演变到一定阶段后,基本都可以做到在不定位故障的情况下快速恢复,当然要做到影响面越大的故障快速恢复,系统架构的复杂度和难度也会自然的要求更高,同时要确保不同影响范围情况下的故障快速恢复按钮能100%生效,则需要靠不断的演练来确保。

故障发生主要的一个因素是变更(对线上做的任何影响行为的动作都可以认为是变更),即使是在有强大的系统架构情况下,也需要通过靠控制变更范围来发挥出系统架构具备的故障恢复能力,例如系统已经做到了多机房部署和切换的能力,但变更时同时操作了所有机房(例如最典型的是推配置信息),那么这个时候如果出故障,就完全没办法,最多能依靠的是快速回滚等,因此在系统架构具备较强的故障快速恢复能力的情况下,也要相应的改变变更操作的流程,以控制每次的影响范围。

要发挥出这种大杀器级的故障快速恢复的能力,还有最后一点重要的就是在故障发生后要立刻尝试上面的恢复招数,而不是去分析和定位故障的原因,这需要改变习惯。

所以总的来说,要做到故障的快速恢复,其实是一个体系化的工作,非常不容易,而一旦能做到,那对系统的高可用可以起到极大的帮助,我的团队为阿里制定了一个这样的故障恢复体系的标准,感兴趣的同学可以看看QCon北京上的《分钟级故障恢复的高可用保障》的ppt。

=============================
欢迎关注微信公众号:hellojavacases

关于此微信号:
分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test,以及和大家一起讨论一些Java问题或场景,这里只有Java细节的分享,没有大道理、大架构和大框架。

公众号上发布的消息都存放在http://hellojava.info上。

Borg论文读后感

Borg之前号称是G家内部和PageRanking可以相提并论的同等重量级的东西,在之前终于是对外发论文了,这篇论文一出就引起了很多人的关注,我的团队在这个方面也做了几年,尽管之前从各种渠道也对Borg有一定了解,但论文揭露的很多内容还是我以前都完全不知道的,个人觉得这篇论文还算挺实在的,G家把自己的很多数据、经验都公开出来了,所以确实值得做资源管理和调度的同学看看。

G家内部所有要放到生产环境运行的东西都称为任务,任务到底放到哪台机器执行由Borg来调度和管理,因此Borg掌握了所有生产环境资源的管理,管理的高效就可以极大程度的节省成本,而这也是Borg出名的原因。

论文里讲到的以下一些内容是我自己印象比较深刻的,同样也是我认为一套优秀的资源管理平台很需要学习的:

1. Prod & Non-Prod Tasks
很早以前就知道Borg是把离线的任务和在线的任务放在一起跑的,当时有点好奇的就是那borg是怎么区分像Gmail之类在线应用的,论文里的Prod(Production)和Non-Prod的划分就直接回答了这个问题。

2. Jobs and tasks
每个Job的描述里可以有很多约束性的一些描述,例如操作系统版本,处理器的架构等,这个真心比我们现在内部的资源分配系统强不少,通用能力自然也就好很多,job通过优先级来做资源抢占,级别划分为:monitoring,production,batch and best effort(also known as testing or free),prod jobs也就是monitoring and production级别。
每个task对应的就是一台机器上的一个container(linux container),task描述所需的资源,不过这个资源信息竟然还包括了tcp端口什么的。

3. Utilization
这是我最关心的部分,在这个部分前论文里还讲了不少关于Borg的架构,以及它是如何保障自己的可用性的等等,这块我就不在这讲了。
Borg最主要的一个目的就是通过一个全局的资源管理系统来提升资源的使用率,在这个部分中论文阐述了Borg通过哪些方法来提升使用率。
第一个方法是离线在线任务混部,论文里有讲到大部分其他的公司都是将离线集群和在线集群分开,G家的一个研究分析表明如果G家把它的离线任务和在线任务集群分开,那么G家会大概需要增加20%-30%的机器,G家的机器数应该在500w+,20%就是100w台机器,这这算到成本的话是非常非常夸张的,所以可以看到离线在线混部是节省资源的一个关键手段,当然每家公司这么做带来的成本节省会不一样,论文里写到之所以离线在线混部能达到这么好的效果,主要原因是prod任务通常是为高峰负载来申请的机器数,而事实上高峰时间通常都是非常短的,就意味着prod任务申请的资源大部分时候其实是空闲的,所以Borg的做法是利用prod任务空闲的资源来跑non-prod任务,从而大幅减少机器数,我自己觉得这是Borg区别于目前大部分其他类似东西的最主要的地方,而且也是最本质的地方。

在给任务分配资源时,Borg采用的方法是prod任务直接占用资源,prod任务互相之间不共享资源,Borg会预估这些prod任务能空闲出的资源,分配给non-prod任务使用,之所以很多公司都不这么做,是担心non-prod任务的执行影响到了prod任务。

Borg在资源的隔离上采用的做法为:
Borg按照两种方法来控制overload和overcommitment,overload通过将任务分为Latency-sensitive(LS)和batch两种来控制资源;overcommitment则通过任务对资源的占用划分为compressible(例如cpu、I/O带宽)和non-compressible(例如内存、磁盘空间)。
如果机器上non-compressible的资源不够用了,那么Borglet会立刻按照优先级杀掉本机上优先级低的任务释放出资源;如compressible的资源不够用,那么Borglet会先尝试控制batch任务对cpu的使用来度过高峰,如果还不行,就会由borgmaster拿掉机器上的一个或更多的低优先级任务。
Borglet里面还有一个用户态的程序来控制分配给prod和non-prod任务的内存,如内存超过了task的限制,或本机的内存不够用了,内核中处理OOM事件的部分将按照优先级来kill task。
在CPU方面,在资源的分配上,对于LS tasks允许占用整个cpu核,而batch tasks则可以在任何核上运行,但batch tasks会在较低优先级上,Borg修改了内核的CPU调度器,允许根据每个container的load状况来动态决定是否要kill batch tasks,同时避免多个LS tasks在一个cpu上争抢,目前Borg仍然在尝试的是在cpu调度时更好的考虑线程亲和、NUMA亲和之类的。

可以看到Borg为了能实现离线在线混部,在资源的分配、隔离上还是做了很多改进的,如果这些patch能公开出来就好了,否则的话其实多数公司做的话也只能是重新尝试,靠不断摔跤来绕过这些问题。

论文的最后有总结下Borg的好和不好的地方,其中竟然也提到了一台物理机一个ip所有container共享的问题,从我们实际对container的使用来看,运维更友好的话其实还是每个container一个ip比较好。

尽管论文中有提到其他很多相似的系统,例如mesos,yarn,facebook’s tupperware,ms autopilot,甚至还提到了alibaba的fuxi,但我始终觉得这些和Borg的巨大区别就是Borg是用来管理所有资源,并且离线在线混部的,而上面这些相似的基本都只是某一款软件的资源管理,这在资源的利用率上相比的话会完全不是一个档次。

据之前的信息,Borg在G家内部应该在2005年左右就相当成熟了,而我们看到论文的时候已经是2015年了,这个差距…

国内腾讯、百度也都尝试过类似Borg的方向,目前腾讯基本是不玩了,百度的Matrix则成功了,同样是离线在线混部,由于给百度节省了巨多的成本,所以这个团队之前得到过百度的100w大奖,不过百度的Matrix其实和Borg实现上的话还是不太一样的,从Borg论文可以看出Borg的话是所有的调度器,这样实现的话有一个坏处是会比较重,百度的Matrix选择了一条更轻量的改造路线,对于一个有不少历史包袱的公司来说是不错的选择,对Matrix感兴趣的同学可以看看这篇文章

我自己这边的话其实是在去年下半年才想明白我们原来所做的提升资源利用率的方向一定程度是错误的,现在我是比较坚信在线离线混部,区分好prod、non-prod,内核改造是比较好的提升资源利用率的方向,我的团队今年在这块需要重点突破,欢迎有兴趣的同学加盟,:)

=============================
欢迎关注微信公众号:hellojavacases
题目来源:http://www.wired.com/wiredenterprise/wp-content/uploads/2013/03/borg.gif

关于此微信号:
分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test,以及和大家一起讨论一些Java问题或场景,这里只有Java细节的分享,没有大道理、大架构和大框架。

公众号上发布的消息都存放在http://hellojava.info上。

加机器、切流量真的那么low吗

每当说到应对活动高峰流量的策略时,加机器这招总是会被认为很low,而同样,在另外一个场景中,当系统出现问题,通过切流量来快速恢复时,也会被认为很low,但这两个大招真的很low吗?

第一个点:加机器
首先说说加机器这回事,通常系统最早都是由一台应用机器再加一台或两台数据库机器组成,访问量高的情况下,自然最希望的就是靠加机器来解决。

简单分开看看,应用机器直接从一台变成两个,在技术上会有一些问题是要解掉的:
1. 应用的状态问题
例如最常见的会有用户的登录信息,也许还会有一些其他的状态信息,而如果不解决这些状态数据的问题,就会导致用户访问两台机器时不一致的现象;
2. 一台到两台组集群的问题
这里也将涉及到一堆的问题,例如负载均衡、健康检查等。

如果是数据库加机器呢,就更加复杂了,在技术上通常要解决分库分表的问题,如果不做分库,那么即使加数据库机器也分摊不了压力,分库通常是物理上的拆分,而如果是同一张表的压力,那么通常还需要做分表。

而随着应用机器数的增长,到数据库的连接池很容易成为瓶颈,这个时候通常会碰到有钱买机器,但不能加机器的致命现象,因此也是必须去解决掉的。

仅仅从上面这个最简单的过程就可以看到,系统要纯粹做到靠加机器就能支撑流量其实并不容易,是需要相当多的技术支撑的,就更不用说,当系统复杂到演变为下面的场景时:
当系统演变为由几百、几千个应用组成的时候,要做一次活动,请问到底要加多少机器,每个应用又加多少台呢;
加的机器一个机房都装不下的时候,那该怎么办呢;

很多时候架构演变要解决的主要问题就是怎么让系统能做到仅靠加机器就能支撑增长的流量,规模问题随着规模的数量级的变化,遇到的挑战会更加的大,从而也会导致系统的架构更加复杂。

这里还没有说加的机器实在太多了,成本该怎么控制住的问题,所以要做到加机器其实真心不low,一个极强的架构师,需要能根据人力的投入、规模增长的预期来权衡在一个架构版本中需要支撑到的规模级别,合理设计架构,从而确保在一个周期内可以仅靠加机器就解决,并同时又确保了在下一个周期到来前已经做好了各方面的技术积累和准备。

第二个点:切流量
有些人看到阿里这边碰到系统出问题的时候切流量这招,会觉得很low,但事实上我们简单来看下,切流量通常指的是把一个机房的流量切到另外一个机房,初级的版本是切流量到同城的另一个机房,这里要解决掉一些技术问题才能做到:
1. 数据库等的地址切换,当做流量切换时,通常是一个机房内出了不确定的故障,因此通常数据库也需要做好主备的切换,除了数据库外,可能还会有其他的一些指定的地址,这个时候都应该做到在不需要重启应用的情况下完成地址切换,这说实话如果在一开始系统简单的时候没有管理好这些地址类型的信息的话,等到系统复杂了再来做这个还是挺花时间的;
2. DNS disable vip,这里就是一个很容易被说到的点,DNS是没有健康检查的,因此当要拿掉一个机房的vip时,就必须等待dns生效,但其实这个是有一招可以来解掉的。

如果是异地的机房的流量切换,就更加复杂了,由于异地的情况下网络的延时会是一个大型分布式应用没法接受的,这个时候通常会启用异地多点写,而要做到这一点就已经非常不容易了,只有在做到这一点的情况下,才有得说异地机房切流量这一说,而在做到的情况下,怎么保障异地机房切流量时的数据的正确性是非常关键的点,感兴趣的可以看下我在这片文章里讲的关于异地多活的技术点。

所以和加机器一样,我们可以看到切流量这招的背后也是需要有强大的技术支持的,我自己是认为切流量是提升系统可用性的极为有效的大招,在多个机房且可以快速切流量(要做到快其实也非常的难)的情况下,单个机房内无论出现任何故障,都可以仅仅靠切流量来应对,这对提升系统的可用时间是非常有帮助的。

欢迎大家讨论这里面讲的一些点,:)

=============================
欢迎关注微信公众号:hellojavacases
题目来源:http://www.bhmpics.com/wallpapers/low_battery_logo-1680×1050.jpg

关于此微信号:
分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test,以及和大家一起讨论一些Java问题或场景,这里只有Java细节的分享,没有大道理、大架构和大框架。

公众号上发布的消息都存放在http://hellojava.info上。

我所关注的Java问题(Cont.)

上篇遗漏了两个关心的问题忘了写,继续补充下。

第一个是类隔离的问题,相信多数的Java开发同学都被类冲突的问题折磨过,maven为避免类冲突起到了一定的作用,但对于groupId、artifactId不一致,但又有同样full classname的类冲突,maven也无能为力,很不幸的是这种无节操的行为在Java应用中相当的多,即使是开源的项目中也一堆这种,因此类冲突带来的问题经常会是大家已知的一个不定时炸弹,但又不想去解决,等着看看Java 9中最重要的模块化的功能会实现的怎么样,话说模块化这功能推了真心够多年的。

第二个是Java应用对硬件资源消耗的分析工具,例如在目前的情况下,如果想知道一个Java应用的CPU消耗是哪些代码造成的,还真的是相当的折腾,perf和JVM的结合不是很好,本来perf应该是足够了,内存如果想知道主要是哪些代码造成的消耗,也同样非常折腾,尽管有Flight Recorder会起到一定的帮助作用,不过这块真心没看到官方有什么想法,估计只能靠自己。

关注的Java问题这篇没得到什么回应,或者换个问法,大家对Java有什么期望吗,你会期望Java支持一些什么特性,原因是什么。

Oracle官方的JDK 7又停止更新了,让大多数人估计都一定程度陷入了尴尬,尤其是对于用6的同学,稍微调查下大家现在用的JDK是什么版本呢?

=============================
欢迎关注微信公众号:hellojavacases

关于此微信号:
分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test,以及和大家一起讨论一些Java问题或场景,这里只有Java细节的分享,没有大道理、大架构和大框架。

公众号上发布的消息都存放在http://hellojava.info上。

我所关注的Java问题

Java作为一个发展了多年的语言,由于历史包袱等原因,自然会有不少问题,这里讲的是Oracle Hotspot(其他的JVM会有些不同),我最关注的主要是以下几个:

1. 对大内存的支持
内存容量发展越来越大,而自然Java应用也会越多的面对大内存的场景,目前Java在大内存的情况下,有两个主要的问题:
* GC问题,CMS GC最大的问题是碎片,碎片所导致的不可预知的Full GC的行为是非常可怕的,我们都有好几个应用开始要在每天低峰的时候强制执行full gc来避免碎片问题,G1GC也仍然是有碎片问题的…
* 排查问题,大内存的情况下dump、分析目前的Hotspot支持的都非常糟糕。

2. 启动瞬间慢的问题
Hotspot在刚启动时是解释模式,逐步才编译为native代码,因此一定会出现启动瞬间慢的现象,这个问题很容易导致有些访问量很高的应用在启动瞬间会出现非常多的请求失败的现象,尽管目前Hotspot也做了很多的努力,例如TieredCompilation等。

3. coroutine
很多的Java应用在处理请求时都会有大量的访问后端的行为,例如访问数据库、调用其他应用等,由于是线程模式,会导致在支撑很高的并发时会比较容易达到瓶颈,而coroutine对于类似这样的场景,会有不小的帮助。
而更进一步,对于分布式的Java应用来说,在一次请求中可能会有大量的并行的后端调用,这种时候如果是线程模式也不是很好做。

4. 序列化/反序列化
这个算比较特殊的一个点,在一次请求要访问非常多后端的情况下,序列化/反序列化通常会成为很重要的一个CPU的消耗点,而根据我们以往的排查我们能看到主要的原因还是在序列化/反序列化中从对象到流,以及从流到对象的过程,所以如果能在这里有突破的话,会对分布式的Java应用有很大的帮助。

5. 字符串append
之前我们在分析Java应用的内存消耗时,会看到StringBuilder/StringBuffer.append造成的char[]数组的扩充造成了主要的内存消耗,而其实这个如果有改进是可以大幅减少内存消耗的压力的(在我们的很多应用上,我们可以看到在很高并发量时GC占据的CPU还是不少的)。

这里还有一个牛人写的JVM implementation challenges的pdf,感兴趣的也可以看看。

你有什么特别关心的Java问题呢,也可以回复我说说看。

=============================
欢迎关注微信公众号:hellojavacases

关于此微信号:
分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test,以及和大家一起讨论一些Java问题或场景,这里只有Java细节的分享,没有大道理、大架构和大框架。

公众号上发布的消息都存放在http://hellojava.info上。

说说高大上的职业规划 for “码农”

职业规划,这个词说起来总感觉很虚,还有点高大上,不过对于几十年的职业生涯而言,职业规划确实还是挺重要的(尤其是工作了几年以后),说说我对“码农”的职业规划的看法(适合往管理方向发展的就不在这里说了),求轻拍。

“码农”主要分业务研发和基础研发,业务研发包括了各种编码实现业务的研发和架构师;基础研发包括了各种更偏基础技术产品的研发和架构师,例如内核、JVM等。

业务研发适合的发展方向我认为是业务PD、业务研发架构师和基础研发,业务研发要做好我觉得除了基本技术外,最重要的是商业敏感性,商业敏感性决定了在实现业务的时候能否为业务将来的发展模式做好铺垫,避免业务变化导致结构推翻,如果商业敏感性不错,可以考虑往业务PD或业务研发架构师的方向发展,更喜欢偏技术一点的话就选业务架构师,更喜欢偏纯业务的话就选业务PD,如果商业敏感性不是很够或没兴趣,并且对基础技术更感兴趣的话,我觉得更适合的发展方向会是朝基础研发方向发展。

基础研发适合的发展方向我认为是基础研发专家、平台架构师和业务研发。

如果优势更偏向于商业敏感性,适合的是转向业务研发方向发展。

基础研发专家和平台架构师这两个发展方向主要取决于个人对专和广的爱好,例如像JVM、内核就是非常专的方向,如果个人的兴趣和优势主要是做这类专的方向,我觉得整个职业规划是最好做的,就是在某个领域不断深挖就行,这类方向在大规模的公司中需求会比较强烈;另外一个方向是平台架构师,平台架构师适合喜欢在广度上发展的同学(或者没能力在专业领域做深),平台架构师最需要的是技术的广度、视野、眼光和平衡的能力,技术的广度是指技术的全栈掌握,软件不仅仅是编码实现,还得考虑实现后运行起来需要投入的成本、持续维护的能力,视野是指掌握业界在相应技术领域更前进一步的做法,眼光是指能够看到技术领域的发展方向,并且能够看到业务将来发展会带来的基础技术的挑战,平衡是指能根据现状(团队、目前的结构、时间)来权衡架构的发展节奏,这个是最难做到的。

所有的发展方向其实都不存在哪个能NB,哪个更low的问题,只有哪个更适合自己的问题,这主要取决于个人的优势和兴趣,另外还需要考虑的一个因素是长期的职业规划,例如以后是想创业做CEO,想加盟创业公司做CTO等,这也会很大程度影响到在一家公司的职位的选择。

最后例行的夹带点私货,:),我的团队很适合往基础研发专家、平台架构师方向发展的同学,在基础研发专家方向上提供了专业的性能、成本和可用性的三个方向,这三个方向的团队成员将专注于相应领域的技术,并且向全局业务负责;在平台架构师方向上我的团队所在的部门是一个全栈技术的部门,涉及到软件架构、服务器、网络、IDC等,对拓宽技术广度会有很大的帮助,这对成为一个平台架构师非常重要,另外我的团队也同样提供了专职做架构的职位,去考虑规模和业务多元化发展带来的架构挑战的问题,感兴趣的同学可以微信回复来联系我,非常期待!

=============================
欢迎关注微信公众号:hellojavacases

关于此微信号:
分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test,以及和大家一起讨论一些Java问题或场景,这里只有Java细节的分享,没有大道理、大架构和大框架。

公众号上发布的消息都存放在http://hellojava.info上。

服务化,你真的需要吗

服务化,SOA,绝对是一个火热了N年的词,再加上各大互联网公司在讲各自的技术架构演进时,基本都会提到服务化,这个诱惑的很多人都想对系统做服务化的改造,但你真的需要服务化吗?

所谓的服务化,是指根据业务的职责划分为多个系统,系统之间的交互以服务的方式进行,这样的好处看起来就是系统的职责变得非常清晰。

但其实呢,服务化并不仅仅是一个纯粹的技术改造,服务化就意味着业务是由多个系统构成,这个时候首先会产生的第一个核心问题是需要有相应的人员来维护,在服务化之前,通常来说模式都是一个系统,所有的开发共同维护一个系统,而服务化拆成多个系统后,就不可能所有的开发再共同维护了,因此做服务化之前,首先要做的第一点是组织结构的调整要对应的准备好,所以其实如果开发人员不多的话,显然是没必要做服务化的,否则连开发的人都不够分,Jeff Dean在有一次的topic上讲到服务化带来的一个好处:easier to have many engineering offices around the world.

另外,有很多想做服务化的原因是觉得服务化后职责清晰,开发效率更高,但事实上是,服务化后变成了多个系统,很多时候会出现为了实现一个需求,需要改多个系统(尽管服务化本来是希望能减少这种现象,但事实上很难做到),协调多个团队,而在一个系统的情况下,通常是每个开发都为整个系统负责,所以在实现需求时是可以一个开发搞定,这样的效率其实通常是更高的,所以其实我始终认为,服务化了以后整个开发效率是一定程度下降的,但好处是它可以支撑很大规模的开发团队。

所以从上面大家可以看到,服务化是在发展到一定情况下才需要做的,我自己觉得触发要做服务化的主要原因会是这三个:
1. 底层例如数据库连接到达上限
系统共用的底层资源在随着机器增加的越来越多时,一定会成为瓶颈,这种情况下服务化会带来帮助,当系统逻辑变简单的情况下,吞吐量自然也比较容易上升,这个时候使用底层资源的机器数自然可以大幅下降。

2. 开发人员规模庞大
当开发人员规模变大(100个左右)时,众多人共同维护一个系统会变得不可行,这个时候服务化可以产生巨大帮助,也会成为必须做的事情。

3. 业务多元化,共享的业务逻辑多
当业务朝多元化方向发展时,各个业务可能会有很多共享的业务逻辑出现,这个时候服务化会带来帮助,不过通常业务多元化也会自然带来开发人员规模庞大,不过这个方式在逐步发展中也会出现一些问题,但总体来说这种情况下服务化还是必须做的。

服务化改造还会带来其他一些问题,感兴趣的可以参见我以前写过的一篇《服务框架演变过程

如果没有上面的那些原因的话,我的建议都是能不做服务化的话还是尽量不要做。

所以一个架构师在做架构改造的决定时,最重要的是要考虑全面(各种平衡),很有可能架构改造并不仅仅是技术层面的事,并且需要判断架构改造发生的合适时间点。

=============================
欢迎关注微信公众号:hellojavacases

关于此微信号:
分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test,以及和大家一起讨论一些Java问题或场景,这里只有Java细节的分享,没有大道理、大架构和大框架。

公众号上发布的消息都存放在http://hellojava.info上。

一个Web应用访问偶尔慢的Case

在等待双11高峰来临之际,先来分享一个前几天排查的问题的case,这类case是目前我觉得排查起来挺折腾的。
ps: 大家都觉得我最近分享的cases在减少,一方面是很多重复的case,另外一方面是我这边有了一个专门排查问题的团队,很多的排查都由这个团队来承担了,之后我也会分享下这个团队的同学的文章,也欢迎有兴趣百分之百投入在问题排查、经验总结和更好的设计高可用系统的同学加入。

问题的现象是:
一个web应用的功能访问会间隙性的慢,但从server端来看指标一切正常。

排查过程:
首先看server端的状况,据用户反馈,包括我自己访问这系统的页面确实会间隙性的慢,重现倒不是太复杂,登录到server上,看历史的load、cpu等指标状况,一切都很正常。

查看gc log,也一切正常。

查看nginx的access log,可以看到响应时间都挺快的,没看到慢的现象。

到这步基本可以确定问题不在server端,对于web类型的应用慢的现象,问题不在server端的时候,对我来说就是排查最折腾的时候,因为前面的链路其实是比较长的,而且我自己其实也不太擅长。

因为访问时快时慢,问题又不在server端,首先怀疑是不是负载均衡上有问题,于是先拜托负载均衡的同学查有没有问题。

在chrome上刷页面,注意到的一个现象是慢的时候tab上的图标主要是在逆时针转,对chrome熟悉的人会知道这说明主要是在dns解析或建到服务器的连接速度慢。

继续用chrome的dev tool跟踪了下时间消耗,发现慢的时候主要消耗在了connection time上,于是更加怀疑是不是负载均衡上建连接的速度出现了时快时慢的现象。

请DNS的同事也帮忙介入了下,DNS的同事注意到一个问题是dns上挂载了两个vip,而其中的一个vip是disable状态。

由于其中一个vip是disable的,导致了dns解析到的地址有50%的概率会连不上,只能等到连失败的情况下才会换到没问题的那个地址,而在找到了没问题的那个地址后,会cache住,等到失效后才有可能再次出现上面的现象,所以表现出来就会是间隙性的慢。

到这一步原因终于是查清了,后来把disable的那个vip去掉,一切就正常了。

最近被好几个web应用访问间隙性慢的问题折腾的不行,一个web请求要进入到后端的server,整个过程相当的长,后端的话现在如果出现慢的现象我们基本可以用eagleeye(之前的文章中有介绍的)来排查,但web请求会比较复杂,如果涉及到网络问题就更加复杂了,我们现在正在计划做一个这样的全链条的工具,以便更好的排查这类问题,如果有谁知道有比较好用的工具,求推荐。

=============================
欢迎关注微信公众号:hellojavacases

关于此微信号:
分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test,以及和大家一起讨论一些Java问题或场景,这里只有Java细节的分享,没有大道理、大架构和大框架。

公众号上发布的消息都存放在http://hellojava.info上。

硅谷一个月之行

9月底的时候去了一趟硅谷,之前的几年也去过几次硅谷,这次的不同在于呆了1个月,比以前更加深度的接触了硅谷的方方面面,分享下自己的感触。

硅谷文化
这次在硅谷拜访了比较多的公司,也和不同公司的人聊了不少,比以前能更加多的感受到硅谷的文化。

接触下来,在公司这个层面,硅谷有很多极为专业的技术创新公司,公司运转的也还不错,里面的员工都非常的专业,多数都是在某个极为专业的领域做了N年的人,一大堆的博士,介绍技术创新的时候很多甚至会涉及到基础科学层面的东西,例如数学、物理、化学。

除了技术创新的公司外,还有更多业务创新的公司,目前美国最火的三家互联网方向的公司缩写为USA,分别是Uber、SnapChat、Airbnb,这三家的市值均超过百亿刀,他们都是业务玩法的创新,Uber、Airbnb都是典型的用碎片化的资源满足碎片化的需求,平台化、轻资产的公司(是不是有点熟的感觉),Uber对出租车行业产生的影响非常大,据说之前已经有出租车排长队在Uber公司楼下集体按喇叭抗议,更不用说现在Uber还扩展到了送快递、外卖等行业,Uber已被Google投资,目前估值180亿美刀;Airbnb除了提高闲置房间的利用率之外,还有一个更重要带来的好处是体验不同的人生风景,在和一些华人吃饭的时候,听到一个90后小孩说Airbnb甚至改变了他的人生观,他住过100多家Airbnb的房子,和不同房东的交流带给了他不一样的人生观,除了USA外(Snapchat不在硅谷),硅谷还有非常多市值不低的公司,像Dropbox、Pinterest等等,另外一个最火的公司说法是湾区四小龙:Uber、Dropbox、Square、Pinterest。

说到硅谷的这些新贵公司们,顺带说下另外一个有趣的现象,就是这些新贵的公司们都在逐渐从旧金山周边的卫星城市(例如以前比较集中的Palo Alto、Mountain View、Santa Clara、San Jose)这些地方搬到旧金山市内,据说主要的原因是年轻人更喜欢在市内工作;另外一个有趣的识别新贵公司的方法:看签到台,新贵公司基本都是一水的iPad自助,而且貌似都是同一套签到系统。

从一堆的技术、业务创新公司可以看出,硅谷在创新能力上还是非常强的,这个和文化、环境、政策有很大的关系,在硅谷基本上很多人会因为有了一个点上的新的想法就创办一家公司,硅谷的人才优势显然也是巨大的,这点对其保持创新的领先也非常的重要。

除了创新以外,硅谷的这些公司给我的另外一点很大的感触是全球化,体现在公司的人员、办公地点还有市场,这点说实话中国的公司还有很大的差距,中国的公司享受着中国的政策、人口红利,很多时候也许只做中国一个市场就已经可以超过硅谷的很多公司,但说实话是很难在硅谷得到尊重的,因为会被认为对世界的前进没起到什么作用,要做成一个全球化的公司,要求其实还是很高的,这点上中国的话估计华为体会是最深的。

不过貌似不少的华人都觉得在非华人的公司,华人的成长空间还是比较有限的,华人的高管确实不多,印度人现在成为高管的倒确实不少,这点对于中国公司进入美国招聘人才倒是有些帮助。

知乎上FB的同学对“大家最想去的IT互联网公司排名”问题的回答也可以看出一些硅谷文化,大家可以看看:http://www.zhihu.com/question/19629180/answer/32191175

硅谷生活
这次在硅谷生活了一个月,比以前每次呆个10天左右的情况确实更加适应了,觉得硅谷生活其实也挺不错的,说说这次在硅谷生活1个月在App、吃、住、行、购物、玩方面的一些感受和建议吧,:)

App
移动互联网时代,App的重要性就不用说了,好的App可以带来极大的便利性,在硅谷生活这段期间,我自己最依赖的是waze、yelp、priceline、skype和微信。

waze很多人估计还不一定听过,是Google收购的一个导航App,它的好用之处在于它是在线型的导航,因此可以通过收集用户的行车速度来更实时的判断路况(不像现在很多的导航软件的路况都是靠交管局信息,延时严重),同时还增加了很多趣味性的社交互动,例如车速慢的时候会跳出个窗口问“检测到车速慢,是否堵车”,大众投票的情况下准确性其实是有保障的,还会有例如前方x米处有警察,前方x米处有车停在路肩,甚至在1号公路上开的时候,还碰到过前方x米处有鹿穿行的提示,是一款非常有爱并且极为有帮助的导航软件(我有好几次都是因为这个绕开了巨堵的地段),无聊的副驾会得到很多欢乐的机会,另外我感觉貌似waze会把需要行进的路线的地图默认离线下载过来,在没有信号的时候也能正常导航,这个还是相当的重要,waze的流量消耗并不高,我每天都用,貌似最后一个月下来应该也没超过200M,因为Google已经收购了waze,所以之后路况等的信息就会共享给Google Map,不需要互动什么的话估计以后Google Map也就可以满足了。

waze是在线导航,所以免不了美国本地手机卡的问题,建议就是不要在淘宝上买,而是下飞机后再买,会便宜多了,而且买起来很方便,只要买prepaid的卡就ok了,甚至很多shopping mall都可以直接自助买,:)

yelp听过的人貌似会更多,可以认为就是美国版的“大众点评”,不过老外貌似是不太喜欢点评餐馆的,所以评论数据不太多,另外老外点评中餐馆的可信度不高,毕竟口味不同,:),但好处是至少可以快速知道附近有些什么餐馆以及大致的评价,所以还是会比较依赖。

priceline最近投资了携程好多次,我自己每次去美国基本都是用priceline来订酒店、租车,用priceline的bid方式的话基本都可以比市场价低个百分之几十订到酒店和租到车,所以我还是挺喜欢用的,:)

skype就很多人听过了,skype优在通话质量高,而且有大陆120通话的套餐,价格只需要9元,很不错。

微信,硅谷的华人圈貌似都用,再加上国内的联系,视频都用微信,还是很赞的。

其他像上面介绍到的uber、snapchat、airbnb,我只用过一次uber,主要是租车了,所以使用uber的需求不强烈,airbnb的话这次没来得及去体验下,旅游的话我觉得还是很值得用的,市内通行或不租车的话我觉得uber非常值得推荐。


以前去硅谷,我最受不了的就是吃,很难习惯,不过这次呆的时间长一些,貌似完全适应了,中西餐基本都ok,而且西餐的分餐制对我这样比较挑食的人其实挺爽,总是能挑到自己可以吃的东西,:)

中餐的话由于这次有硅谷各路的朋友带着去吃,吃到了不少好吃的中餐馆,甚至觉得比国内的中餐还好吃,一定程度上是因为原材料的原因,推荐几家中餐馆:
little sichuan(中文现在叫福恩园,在San Mateo Downtown)、Henry’s Hunan Restaurent(位于旧金山市内)、Chef Zhao(在Moutain View附近吧)、Cooking Papa(粤菜,有好几家,MountainView这家吃过,很赞)、Little Sheep Hotpot(小肥羊,我一直觉得比国内的好吃)、上海乔家栅(在Cupertino Village)、清真一条龙(在Milpitas Square),还有很多好吃的中餐馆,大家可以找硅谷的朋友们帮忙推荐,像听说的没去吃成的还有鲤鱼门、韶山冲。

西餐我就不知道了,对我来说就是肋排,:),其他的我说不上喜欢吃,肋排的话我觉得吃过的Willy’s、Outback都还不错,据说Bob’s的也很好吃,早餐的话我挺喜欢Jack in the box、Denny’s这些地方。


住的话这次折腾了好几个酒店,我自己不是很喜欢住Downtown之类的地方,所以我是觉得住在SF bay的几个城市挺好的,例如Brisbane、Burlingame、Foster,喜欢住市内的就另说,硅谷有挺多Suites类型的酒店,挺赞的。
旅游的话我觉得Airbnb去体验下是挺好的,值得推荐,不过这次忘了找Airbnb的朋友帮忙推荐几家。
在住上这次的感觉就是貌似硅谷的酒店比两年前贵了不少,连在priceline上都很难用低价bid到好一些的酒店。


在硅谷我觉得没有车还是很不方便的,吃饭、购物、玩什么的基本都得开车,不过还好就是租车并不复杂,而且价格也ok,租车的价格更多的是保险,说到这个,就必须说一定要记得带墨镜去,加州的阳光,那绝对不是盖的。

交通的话很发达,很多地方都是高速直达,并且都是免费的,在硅谷我都已经觉得20km什么的不算个啥,觉得很近,再加上硅谷这边开车基本都是极为遵守交规,我貌似只听到过三四次喇叭,而且好像有两次还是我自己引发的,和同事开玩笑说,在硅谷开车遵守交规,其实很多时候都是不好意思逼的,看着其他人那么礼让和遵守,自己都不好意思不遵守,另外我觉得老美开车还是相当快的,和中国的不同就是路上的车的行进速度都很快,所以即使车流量大,通行还是很不错的,不像中国,路上的车什么速度的都有,导致有些时候不变道根本没法开,由于老美开车速度都比较快,变道什么建议还是保持一定的提前量。

硅谷都是自助加油,中国的信用卡一般不能直接操作,需要找店员说然后才能自助加。

购物
硅谷地带有很多的shopping mall,比较出名的是几个outlet,例如Livermore Outlet,去这些地方一定要先去Guest Service拿个Coupon Book,可以享受折上折,在这些地方线下买东西会发现很多时候折上折后确实很便宜,amazon都没法比,所以感觉美国的电商貌似主要是靠便利性和商品的丰富性来形成优势,价格上我觉得倒是没什么优势,其他的shopping mall建议直接地图搜索shopping mall或shopping center,通常很轻松就能找到一堆,基本上要买的东西这些地方都可以买到的,实在不行的话还可以选择直接amazon或其他的一些电商网站直接买,然后寄到酒店就ok。
超市方面我觉得Target、Safeway之类的都挺好的,Costco的话适合批量买东西,价格便宜,而且需要有卡(不在美国居住的人貌似没法办的)。

顺带说下,很多东西硅谷并不贵,包括衣服,所以建议不用带太多的衣服什么过去,另外,美国好像都不怎么晒衣服,衣服都是直接烘干,洗衣服的话还是比较方便的,有些酒店会有自助洗衣机,如果没有的话也可以找找附近的clean & dry之类的店。

购物要注意的是回国时候的行李托运问题,要注意坐的航班允许托运的件数以及重量。


旧金山Downtown玩的地方貌似就是金门大桥、City Hall、Union Square、渔人码头、九曲花街、Twin Peak、金门公园等吧,金门大桥开到山上后可以继续往那边山下开,那下面有个沙滩我觉得挺不错的,还有彩色的石头,应该是叫Marin Headlands;Twin Peak适合晚上去,可以看整个旧金山的夜景。

周边不能错过的玩的地方是著名的加州1号公路,可以直接搜Pacific Beach,然后再导航到17Mile或Carmel都可以,这个中途千万别错过The Pigeon Point Light,这条公路被称为世界上最美的10条公路绝对不是吹的,沿途的风景非常的赞,如果有长的假期,例如15天以上,沿着这条路一直开到洛杉矶,确实赞,沿途可以欣赏到各式各样的风景,话说老美貌似还是挺热衷户外运动的,冲浪、hiking、骑车等等,一路上都能看到很多。

另外像著名的斯坦福大学、加州伯克利都是值得去去的,对于做IT的人来说,Google旁边的计算机历史博物馆我觉得也值得看看,对于VC的话,Sand Hill还是值得晃荡下,还有像Palo Alto的富人区也可以参观参观,那里有乔布斯的House,还有像Mark、Google的Page等也都在那有House。

总的来说,这次呆过后的感觉是硅谷在高科技领域的氛围确实很赞,信息、人才的流动都很顺畅,所以在这里确实很容易接触到更新的东西,更前沿的科技,生活方面嘛空气质量好(尽管很多老外和我说硅谷的空气质量已经不算好的),吃什么也都不错,比以前几次到硅谷觉得没法生活的感觉好了很多,已经觉得其实在硅谷生活一段时间也挺好的,不过长期呆会怎么样仍然不确定,:)

=============================
欢迎关注微信公众号:hellojavacases

关于此微信号:
分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test,以及和大家一起讨论一些Java问题或场景,这里只有Java细节的分享,没有大道理、大架构和大框架。

公众号上发布的消息都存放在http://hellojava.info上。