IT瘾工作推荐

极简 Java 工作流概念入门

Fri, 26 Aug 2022 15:36:38 CST

关于 Flowable 松哥已经更新了好几篇文章了，不过考虑到有的小伙伴可能还从来没接触过流程引擎，因此有一些基础的内容我再来和小伙伴们梳理一下。

1. 为什么需要工作流

松哥将之前的文章转发到朋友圈后，有小伙伴评论说一直不理解为什么需要工作流，今天我们就先来说说这个话题。

假设我有一个请假需求，流程如下：

请假可以提交给我的上司，上司可以选择批准或者拒绝，无论批准还是拒绝，都会给我一个通知。

这个流程比较简单，我们很容易想到解决方案，不用工作流也能解决，有一个专门的请假表，当 A 要请假的时候，就往请假表中添加一条记录，这条记录的内容包含了请假的天数、原因、请假的审批人 B 以及一个名为 status 的字段，这个 status 字段表示这个请假申请目前的状态（待审批、已批准还是已拒绝），然后 B 登录系统之后，在请假表中查询到了 A 的请假信息，然后选择批准，此时将 status 字段的值改一下就行了。

这个流程很简单，相信小伙伴们都能想到。

然而，这是一个非常简单的流程，对于这样的流程，一般来说也确实没有必要使用工作流，但是现实中，我们涉及到的工作流往往都是非常复杂的，我举个例子，就说报销审批吧，这个可能很多小伙伴都经历过。

小伙伴们看到，这个流程相对来说还是比较复杂的，此时你再用一个 status 字段去描述，就很难说的请到底是怎么回事了。每一步审批，都有可能批准也有可能拒绝，拒绝并不意味着流程结束，员工修改报销资料之后，还可以继续提交。此时如果还用 status 去描述，那么 status 将有 N 多个值去表示不同的情况，这个维护起来非常不便。

这就复杂了吗？非也非也，我们再来看一个生产笔记本电脑的例子，假设公司研发了一款新型笔记本电脑，整个研发到生产的流程可能是这样：

相比上面两个，这个就更复杂一些了，不仅有串行任务还有并行任务，如何去设计这样一个系统？单纯的通过状态字段去描述显然已经不够用了，此时我们就得考虑一种通用的、更易维护的方案来实现这样的系统了，这种通用的、易维护的方案，也就是工作流。

2. 三大工作流

一个比较早的工作流是 jBPM，这是一个由 Java 实现的企业级流程引擎，是 JBoss 公司开发的产品之一。

jBPM 的创建者是 Tom Baeyens，这个大佬后来离开了 JBoss，并加入到 Alfresco，并推出了基于 jBPM4 的开源工作流系统 Activiti，而 jBPM 则在后续的代码中完全放弃了 jBPM4 的代码。从这个过程中也能看出来，jBPM 在发展过程中，由于意见相左，后来变成了两个 jBPM 和 Activiti。

然而戏剧的是，Activiti5 没搞多久，从 Activiti 中又分出来一个 Camunda，Activiti 继续发展，又从中分出来一个 Flowable。。。

由于开发 jBPM、Activiti、Camunda 以及 Flowable 的人多多少少有一些关联性，让人不得不猜测意见相左拉一票人出来单干是他们的企业文化。

所以现在市面上主流的流程引擎就一共有三个：

Activiti
Flowable
Camunda

这三个各有特点：

Activiti 目前是侧重云，他目前的设计会向 Spring Cloud、Docker 这些去靠拢。
Flowable 核心思想还是在做一个功能丰富的流程引擎工具，除了最最基础的工作流，他还提供了很多其他的扩展点，我们可以基于 Flowable 实现出许多我们想要的功能（当然这也是小伙伴们觉得 Flowable 使用复杂的原因之一）。
Camunda 相对于前两个而言比较轻量级，Camunda 有一个比较有特色的功能就是他提供了一个小巧的编辑器，基于 bpmn.io 来实现的（松哥之前已经发文讲过了）。如果你的项目需求是做一个轻巧的、灵活的、定制性强的编辑器，工作流是嵌入式的，那么可以选择 Camunda。

如果仔细比较起这三个的差异，能列一个长长的表格，这个网上也有不少人都总结过了，松哥这里也就不啰嗦了。

3. 流程图

既然有三个不同的工作流，那么三个不同的工作流画出来的流程图是否都各不相同呢？

不是的。

工作流程图这块其实有一个统一的标准，那就是 BPMN。BPMN 全称是 Business Process Model and Notation，中文译作业务流程模型和标记法，这个中文太绕口了，还是简称 BPMN 吧。

这是一套图形化表示法，用图形来表示业务流程模型。BPMN 最初由业务流程管理倡议组织（BPMI, Business Process Management Initiative）开发，BPMI 于 2005 年与对象管理组织（OMG, Object Management Group）合并，并于 2011 年 1 月 OMG 发布 2.0 版本，同时改为现在的名称。

一句话，就是流程图这块有一个特别古老的规范，那就是 BPMN，而我们前面所说的无论是 Activiti、Flowable 还是 Camunda，都是支持这个规范的，所以呢，无论你使用哪一个流程引擎，都可以使用同一套流程图。

那么这个规范究竟都说了些什么事情呢？

我们以上面生产笔记本的流程图为例，来和小伙伴们做一个简单介绍：

从上图中可以看到，一个流程图中主要包含四方面的内容：

事件
连线
任务
网关

我们一个一个来说。

事件

首先在一个流程图中应该有开始事件和结束事件，也就是上图大家看到的两个圆圈。另外还有一些中间事件、边界事件等。举个中间定时事件的例子，比如用户下单之后，可以有一个中间定时事件，延迟 5 分钟发货。

连线

连线就是将事件、任务、网关等连在一起的线条，一般情况下就是普通连线，有的时候连线会有一些条件，例如松哥之前文章和大家分享的请假，如果经理同意请假申请，就走哪一个线条，如果经理不同意请假申请，就走哪一个线条。对应上图的笔记本生产，如果经理审批通过，就载入图纸准备生产，如果经理审批不通过，就重新设计。

任务

任务这块其实有很多分类。

如果细分大致上可以分为如下几种：

接收任务

在上面的流程图中，等待准备工作完成这一项就是一个接收任务。这个任务里并不需要额外做什么事情，流程到这一步就自动停下来了，需要人工去点一下，推动流程继续向下执行。

发送任务

这个一般用来把消息发送给外部参与者。

服务任务

这个一般由系统自动完成，其实说白了就是我们的一个自定义类，可以在一个自定义类里边完成想要做的事情。

脚本任务

一个自动化活动。当流程执行到脚本任务时，自动执行相应的脚本。

业务规则任务

BPMN2.0 新引入用来对接业务规则引擎，业务规则任务用于同步执行一个或多个规则。

用户任务

用于为那些需要由人工参与者完成的工作建模。

虽然细分类别很多，但是仔细看，其实这几种又可以归为两大类：

用户任务：表示人工要介入做的事情。比如同意与否，或者输入一些参数，要让人工完成任务，就需要一个表单系统，让人工输入数据，或者显示数据给人看，这也是为什么用户任务和表单系统结合在一起的原因，用户任务需要用户向引擎提交一个完成任务的动作，否则流程会暂停在这里等待。
服务任务：表示机器自动做的事情。调用服务的任务，这个服务可以是一个 Spring JavaBean，也可以是一个远程 REST 服务，流程会自动执行服务任务。

活动

活动可以算是一种特殊的任务。活动可以调用另外一个流程使之作为当前流程的子流程去运行。活动也可以分为用户活动、脚本活动等等。从显示上来说，活动比任务边框深一些。仅此而已。

网关

网关要是细分起来，也有很多不同类型的网关。

互斥网关

这种网关也叫排他性网关，我们之前请假流程中的那个网关，就是互斥网关。这种网关有且仅有一个有效出口。

相容网关

这种网关会有多个出口，只要条件满足，都会执行。

事件网关

事件网关是通过中间事件驱动，它在等待的事件发生后才会触发决策。基于事件的网关允许基于事件作出决策。

并行网关

并行网关一般是成对出现的，上面生产笔记本的那个流程中，生产屏幕、键盘等并行操作，就是通过并行网关来实现的。

好啦，这就是关于流程引擎的一些基本概念，捋顺了这些基本概念，在回过头看我们前面几篇关于流程引擎的文章，应该会有一些不一样的理解：

SRE 的工作介绍

Sat, 06 Nov 2021 23:23:03 CST

有很多人问过我想了解一下 SRE 这个岗位，这是个很大的话题，在这篇博客中把想到的一些介绍一下吧。

SRE 到底是什么？这是一个最早由 Google 提出的概念，我的理解是，用软件解决运维问题。标准化，自动化，可扩展，高可用是主要的工作内容。这个岗位被提出的时候，想解决的问题是打破开发人员想要快速迭代，与运维人员想要保持稳定，拒绝频繁更新之间的矛盾。

SRE 目前对于招聘来说还是比较困难。一方面，这个岗位需要一定的经验，而应届生一般来说不会有运维复杂软件的经历；另一方面就是很多人依然以为这就是“运维”工程师，认为做的是一些低级重复的工作，对这个工作有排斥。最根本的，其实这个岗位寻找的要么是具有运维经验的开发人员，要么是具有软件开发技能的运维工程师。所以比较难以找到合适的人。

在现实生活中，不同公司的 SRE 岗位大有不同，有一些甚至可能还是传统运维的名字换了一个岗位名称。

比如蚂蚁金服有两种 SRE，一种是负责稳定性的，就是大家所理解的 SRE；另一种叫做资金安全 SRE，并不负责服务正常运行，而是负责金钱数目正确，对账没有错误，工作内容以开发为主，主要是资金核对平台和核对规则（没有做过，只是个人理解）。某种意义上说，已经不算是 SRE 而是专业领域的开发了。

Netflix （2016年）的模式是谁开发，谁维护。SRE 负责提供技术支持，和咨询服务。Netflix 在全球 170 个国家有服务，Core SREs 只有 5 个人。

微软有专门的 Game Streaming SRE，负责 XBox 在线游戏的稳定性。

所以不同公司的 SRE 的内容各有偏重，取决于公司要提供什么样的服务。

我们可以学习网络分层的方式，将 SRE 大致的工作内容从下往上分成 3 个大类：

Infrastructure：主要负责最基础的硬件设施，网络，类似于 IaaS，做的事情可参考 DigitalOcean
Platform：提供中间件技术，开箱即用的一些服务，类似于 PaaS，做的事情可参考 Heroku, GCP, AWS 等
业务 SRE：维护服务，应用，维护业务的正常运行

Infrastructure

Infrastructure 和 Platform SRE 其实可有可无，这些年商业化的服务其实越来越多了，比如，如果公司选择全部在 AWS 部署自己的服务的话，那么就不需要自己建立 Datacenter，维护网络之类的工作了，只需要几个 AWS 专家即可。

如果有的话，工作内容也可大可小。可以从管理购买的 VPS 开始，也可以从采购硬件服务器开始。

我觉得 Infrastructure SRE 的工作内容可以这样定义：

负责服务器的采购，预算，CMDB 管理。要知道（能查询到）每一台的负责人是谁，在干什么。这个非常重要，如果做不好，会造成极大的资源浪费。
提供可靠软件的部署环境，一般是虚拟机，或者 bare mental。
操作系统的版本统一维护，Linux 发行版的版本，Kernel 的版本等。
维护机器上的基础软件，比如 NTP，监控代理，其他的一些代理。
提供机器的登录方式，权限管理，命令审计。
维护一套可观测性的基础设施，比如监控系统，log 系统，trace 系统。
维护网络，大公司可能都会自己设计机房内的网络。其中包括：
1. 网络的连通，这个是必要的。对于上层用户（Platform SRE）来说，交付的服务应该是任意两个 IP 是可以 ping 通的，即管理好 3 层以下的网络。
2. NAT 服务
3. DNS 服务
4. 防火墙
5. 4 层负载均衡，7层负载均衡
6. CDN
7. 证书管理

每一项既可以是一个很大的团队，也可以只有一个人去对商业化的 Infra 服务。可以使用开源的产品，也可以自己研发。

Platform SRE

Infrastructure SRE 维护的是基础设施，Platform SRE 使用他们提供的基础设施建立软件服务，让公司内的开发者可以使用开箱即用的软件服务，比如 Queue，Cache，定时任务，RPC 服务等等。

主要的工作内容有：

RPC 服务：让不同的服务可以互相发现并调用
私有云服务
队列服务，比如 Kafka 或者 RabbitMQ
分布式的 cronjob 服务
Cache
网关服务：反向代理的配置
对象存储：s3
其他一些数据库：ES，mongo 等等。一般来说，关系型数据库会有 DBA 来运维，但是 NoSQL 或者图数据库一般由 SRE 维护。
内部的开发环境：
1. SCM 系统，比如自建的 Gitlab
2. CI/CD 系统
3. 镜像系统，比如 Harbor
4. 其他的一些开发工具，比如分布式编译，Sentry 错误管理等等
一些离线计算环境，大数据的服务

业务 SRE

有了 Platform SRE 的支持，开发人员写代码就基本上不需要关心部署的问题了。可以专注于开发，使用公司开箱即用的服务。这一层的 SRE 更加贴近于业务，知道业务是怎么运行的，请求是怎么处理的，依赖了哪些组件。如果 X 除了问题，可以有哪些降级策略。参与应用的架构设计，提供技术支持。

主要的工作内容有：

参与系统的设计。比如熔断、降级，扩容等策略。
做压测，了解系统的容量。
做容量规划。
业务侧的 Oncall。

对于一个专业的 SRE 来说，上述技能也不应该有明显的界限，比如说业务 SRE 也需要掌握一些网络技能，Infra SRE 也要写一些代码。很多工具每一个岗位的人都多少用的到，比如 Ansible/Puppet/SaltStack 这种 IT 自动化工具，或者 Grafana/Prometheus 这种监控工具，只有理解才能用的正确。换个角度讲，对于业务 SRE 来说，虽然基本上不会去管理四层以下的网络，但是如果遇到网络问题，能通过已有的工具和权限排查到交换机问题，去找 Infra SRE 帮忙：“请帮我看下 xx IP 到交换机是否有异常，因为 xxx 显示的结果是 xx”，总比 “我怀疑 xx 有网络问题，请帮忙排查下” 要好一些吧？

以上是工作职责的大体划分，这个分层其实没有什么意义，倒是可以让读者了解一下 SRE 都涉及哪一些工作。

下面是一些日常的工作内容。

部署服务

部署分成两种：

Day 1：将服务部署上线的那一天
Day 2+：服务部署之后，还会进行很多更新，升级，配置更改，服务迁移等等

Day2+ 的工作要做很多次，Day 1 做的很少，在不断的迭代升级之后，还能保证有一个可靠的 Day 1 操作是很难的。换句话说，我们在服务部署之后一直改来改去，还要保证这个服务在一个全新的环境能够可靠的部署起来。部署环境的硬编码，奇奇怪怪的 work around，都会破坏 Day 1 的可靠性。之前一家公司，扩容一个新机房的过程简直是噩梦，太多的奇怪配置，hardcode，导致踩过无数个坑才能在一个新的机房部署起来全部的服务。

Day2+ 的操作也不简单，主要要关注稳定性。对于重要的变更操作要设计好变更计划，如何做到灰度测试，如果出了问题应该如何回滚，如何保证回滚可以成功（如何测试回滚）等等。

部署的操作最好都是可以追踪的，因为并不是所有会引起问题的操作都会立即引起问题。比如一个操作当时做完没有什么问题，但是过了 1 个月，偶然的重启或者内存达到了某一个指标触发了问题。如果能记录操作的话，我们可以回溯之前做过的变更，方便定位问题。现在一般都用 git 来追踪部署过程的变更（ gitops）。

Oncall

Oncall 简单来说就是要保证线上服务的正常运行。典型的工作流程是：收到告警，检查告警发出的原因，确认线上服务是否有问题，定位到问题，解决问题。

收到告警并不总意味着真正的问题，也有可能告警设置的不合理。告警和监控面板并不是一个静态的配置，它应该是每天都在变化的，时刻在调整的。如果发现没有标志真正线上问题的告警发了出来，就应该修改告警规则。如果发现当前的监控无法快速定位问题，应该调整监控面板，添加或者删除监控指标。业务在发展，请求量在变化，某些阈值也需要不断地调整。

定位问题没有一概而论的方法了，需要根据看到的实时，结合自己的经验，然后做推测，然后使用工具验证自己的推测，然后确定问题的根因。

但是解决问题是可以有方法论的，叫做 SOP，标准操作流程。即：如果出现了这种现象，那么执行那种操作，就可以恢复业务。SOP 文档应该提前制定，并且验证其有效性。

需要注意的是上述定位问题、解决问题 并没有顺序关系。一个经常犯的错误是，在出现故障的时候，花了很长时间定位到故障的根因，然后再修复。这样花的时间一般会比较长。正确的做法是先根据现象看现有的 SOP 能否恢复业务。比如说当前错误只发生在某一个节点上，那么就直接下线这个节点，具体的原因后面再排查。恢复当前的故障永远是第一要务。但是恢复操作也要经过测试，比如猜测可以通过重启解决问题的话，可以先重启一台做测试，而不是一次性将所有服务重启。大部分情况是需要临场分析的，是一个紧张又刺激的过程。

故障到底多久恢复算好？出现多少故障是可以容忍的？怎么标志服务的稳定性到底如何？我们使用 SLI/SLO 来衡量这些问题。

制定和交付 SLI/SLO

维护服务等级协议，听起来像是一个非常简单的事情，只要“设定一个可用率”然后去实现它就好了。然而现实的情况并不是。

比如，制定可用率的时候，并不是说我们去“实现4个9”（99.99% 的时间可用）就够了，我们有以下问题要考虑：

如何定义这个可用率？比如我们以可用率 > 99.9% 为目标，有一个服务部署了 5 个 Zone, 那么有一个 Zone 挂了，其余的 Zone 是可用的，那么可用率被破坏了吗？这个可用率是每一个 Zone 的还是所有的 Zone 一起计算的？
可用率计算的最小单位是什么？如果 1min 内有 50s 没有达到可用率，那么这一分钟算是 down 还是 up？
可用率的周期是怎么计算的？按照一个月还是一个周？一个周是最近的 7 天还是计算一个自然周？
如何对 SLI 和 SLO 做监控？
如果错误预算即将用完，有什么措施？比如减少发布？如果 SLI 和 SLO 没有达到会怎么样？

等等，如果这些问题不考虑清楚的话，那么 SLI 和 SLO 很可能就是没有意义的。SLI/SLO 也适用于对公司内部用户的承诺，让用户对我们的服务有预期，而不能有盲目的信任。比如 Google 在 SLI/SLO 还有预算的时候，会在满足 SLI/SLO 的时候自行对服务做一些破坏，让用户不要对服务有 100% 可用的错误预期。SLI/SLO 也会让 SRE 自己对当前服务的稳定性有更好的认识，可以根据此调整运维、变更、发布计划。

故障复盘

故障复盘的唯一目的是减少故障的发生。有几个我目前认为不错的做法。

故障复盘需要有文档记录，包括故障发生的过程，时间线的记录，操作的记录，故障恢复的方法，故障根因的分析，为什么故障会发生的分析。文档应该隐去所有当事人的姓名对公司的所有人公开。很多公司对故障文档设置查看权限，我觉得没什么道理。有些公司的故障复盘甚至对外也是公开的。

故障在复盘的时候应该将当事人的名字用代码替代，可以营造更好的讨论氛围。

不应该要求所有的故障复盘都产生 Action。之前一家的公司的故障复盘上，因为必须给领导一个“交待”，所以每次都会产生一些措施来预防相同的故障再次发生，比如增加审批流程之类的。这很扯，让级别很高的领导审批他自己也看不懂的操作，只能让领导更痛苦，也让操作流程变得又臭又长，最后所有人都会忘记这里为什么会有一个审批，但是又没有人敢删掉。你删掉，出了事情你负责。

Blame Free 文化？之前我认为是好的。但是后来发现，有些不按照流程操作导致的问题确实多少应该 Blame 一下，比如下线服务的时候没有检查还没有 tcp 连接就直接下线了，或者操作的时候没有做 canary 就全部操作了，这种不理智的行为导致的故障。但是条条框框又不应该太多，不然活都没法干了。

容量规划

容量规划是一个非常复杂的问题，甚至有一些悖论。容量要提前做好规划，但是容量的规划需要知道业务的扩张速度，扩张速度这种事情又不是提前能计划好的。所以我一直觉得这个事情很难做，也一直没有见过做的很好的例子。

但是至少可以对维护的系统建立一个模型，知道多少机器，多少资源，能容纳多少容量。这样遇到大促之类的活动也能及时估算需要的资源数量。

用户支持

用户支持也是日常的一部分。包括技术咨询，以及用户要求的线上问题排查。

这里就需要提到文档的重要性了。如果没有维护好文档，那么用户就会一遍又一遍问相同的问题。写文档也是一个技术活，优秀的需要很长时间的积累。文档也需要经常更新。我一般会这样，保持这样一种状态：用户可以不需要任何人就从文档中找到他需要的所有答案。如果我发现用户的问题无法从文档中找到，或者难以找到在文档中的什么地方，就会更新文档，或者重新组织文档。如果用户的问题已经从文档中找到，那么就直接发文档给他。如果用户的问题显然是文档看都没有看过（有很多人根本不看文档的，只看文档是谁写的然后径直去问这个人），就直接忽略。

优秀的文档应该尽量引入少的专有名词，少使用没有用处的专业词汇描述，只描述具有指导意义的事实，假定用户没有相关的背景知识，列举使用例子，举一些现实会用到的例子而不是强行举例子，明确 Bad Case。等等。这其实是一个很大的话题了，这里就不展开了。

暂时就想到这一些了。下面写一些我经常见到的误解，和经常被别人问的问题。

有关做项目没有专业团队得不到训练。

这方面是听到最多的抱怨。虽然说 SRE 在工作上应该是开发时间和运维时间各 50%，但是真实的情况是，即使 SRE 有一些开发工作，也大部分是面向内部用户，面向公司内部的开发者的。大部分项目是一些想法，需要去尝试一下行不行，基本上不会有专业的设计资源，PM 资源。这种项目就需要 SRE 有多方面的技能，包括对产品的理解，清楚地知道它有什么痛点，最好是自己经历过的痛点，然后需要懂设计，管理好开发进度。然而这种人非常少。其实能写中型项目代码的 SRE 就已经非常少了。所以大部分公司内部项目都会做的又难用又复杂。

即使是有专业配套 PM 和设计，甚至前端资源。基本上也是一个灾难。我也经历过这样的团队。这种内部项目对标的不是互联网项目，而更像是 toB 的项目。用户 UI 的设计，交互逻辑，操作流程，交付周期等需要的都是另一个领域的知识。否则的话人越多，也只会徒增沟通成本，拖慢项目进度。

回到经常听到的这个抱怨，说在 SRE 的团队没有像开发团队那样有“正规军”，有设计和 PM，大家各司其职，后端开发只要对齐 API 然后实现就好了。大部分的应届生会有这样的幻想，但实际上不是这样。被搞错的最重要的一点是， 学习主要是靠自己的，和别人没有太大的关系。我觉得可能是在一个大团队里面，有很多人一起做一件事情，心里的怀疑和焦虑会少一点，人们会对这样的工作状态感到踏实，误以为是“成长”，自己做所有的工作焦虑更多。

事实是，在大团队工作可能学到更多的沟通技能，比如和不同的人对齐不同的阶段工作目标，要想要学到其他的东西还是要靠自己。比如拿到一个设计，如果照样子去实现了，其实不会学到什么东西。而要去理解为什么这么设计，为什么不那么设计。如果自己去做，思考的过程也基本是这样的，可以怎么设计，选择什么好。都是：思考，选择，尝试，经验，思考……

另一个需要澄清的误区是，模仿并不是学习。在团队中经历了一个设计，如果记住了这个设计，下次碰到类似的问题也用这个设计去解决。这也不能叫做是学习。我见过有在业务部门做过支付的 SRE 写的代码，在内部系统中去实现了订单业务的订单、交易等概念完成一个运维流程，甚至 Model 的名字都没改过。拿着锤子找钉子，会让系统变得更加糟糕和复杂。

总之，工作分的细并不代表工作就会更加专业。一个人身兼数职业可以在每一个方面做得很专业。重要的是不断学习，使用正确的做事方式，向优秀的项目和优秀的开发者学习。

有关脏活累活。

每一项工作都会有脏活累活：学不到什么东西，做起来没有意思。可能是整理系统的监控，可能是整理现有的文档，可能清理一些年久的运维脚本，可能是需要和不同的团队做一些沟通工作等。

这是不可避免的，如果可以的话，学会从每一项工作中找一些偷懒的方法吧，比如用脚本处理一些工作，用更聪明的方式工作等等。

但是如果这种工作的比例太高的话，就要思考工作方式的问题了。如果陷入恶性循环，看能不能从工具和工作流程上做一些改变。如果不能的话，考虑换一份工作吧。

有关背锅。

互相甩锅的工作环境无疑是非常糟糕的工作环境。如果相同的团队、或者不同的团队之间需要相互勾心斗角的话，如果工作环境不允许大方承认（SRE 无可避免地会犯一些错误）自己的错误，说明公司营造的氛围有问题。比如某些公司规定，发生 P1 级别的错误就必须开除一个 Px 级别的员工，发生 P0 级别的错误就必须开除一个 Py 级别的员工一样。如果是这种情况的话，公司实际上是在用一种懒惰地方法通过提高人的压力来提高系统的稳定性。有没有效果不知道，但是确定的是不会有人在这种情况下工作的开心。建议换一份工作。

如何转行？

其实难度没有想象的高，毕竟大学里面没有一个叫做 SRE 的专业。SRE 要求的知识也是编写代码、设计系统、了解操作系统和网络等。所以在大学里面将本科的课程好好学好，尝试做（并维护）一些自己的项目，毕业的时候基本上就满足要求了。非科班的人要转行的话，也可以参考大学的课程内容去补足这方面的知识。

需要注意的是，培训班出来的做开发完成业务可能够，但是做 SRE 远远不够。SRE 不仅需要 make things work，还要知道背后的原理。

面试会问什么？

我觉得和后端开发的面试内容基本上差不多。

如果是去应聘的这个岗位所需要的一些技能，比如 K8S，监控系统等，可能也会问一些领域内的知识。虽说这部分工具性的东西都可以学习，但是如果人家要一个经验丰富的、或者入职就能干活的，那么面试成功的机会就会小很多。当然，也不必沮丧，这是市场的供需关系决定的，如果对方执意要找符合特定要求的候选人，那么对方的选择的范围也会小很多，不必因为错失了这种机会而后悔没去学习什么工具。话又说回来，技能越多，选择也会越多。

排查错误可能是转行做 SRE 最大的一个门槛，这个需要一些经验。如果没有经验的话，就补足一些操作系统的知识，这样遇到未知的问题也可以通过已知的知识和工具去排查。

做 SRE 需要会写代码吗？

会，而且写代码的要求并不会比一个专业的后端开发低。

选择大公司还是小公司？

这属于两种截然不同的工作环境。小公司一般都有一个救火英雄式的人物，在公司的时间比较长，知道所有组件的部署结构，什么都懂。跟着这种人学习会成长很快。

大公司细分领域很多。本文前面列出的内容可能每一项在大公司中都是一个团队，对某个领域可以深入研究。

所以还是看想要做什么了。我个人比较喜欢靠谱的小公司，或者大公司中靠谱的小团队。

如何判断一家公司是否靠谱？

对于 SRE 这个职位，我总结了一些判断的技巧。比如可以判断一下对方目前的业务和 SRE 员工的数量是否处于一个“正常”的状态，人数是否在随着业务（机器的数量）现象增长？这是一个不好的迹象。是否 SRE 的数量过多？如果 SRE 人太多，有两个可能的原因：1）某个领导为了扩大自己的影响力在为一些“不必要的”岗位招人，这样会导致人多事少，大家开始做一些奇奇怪怪的事情，发明奇奇怪怪的需求，以各种各样的方式浪费自己的时间来领公司的工资；2）这个公司的基础太差，大部分工作都是需要人力运维，导致基本上有多少机器就需要多少人。总之，都不是什么好事情。

一些技术比较好的公司，都没有庞大的 SRE 队伍，比如 Instagram, Netflix（现在可能人数不少了），以及一些创业公司，甚至都可以没有专门的 SRE，优秀的 SRE 首先要是开发者，优秀的开发者也离 SRE 不远了。一些耳熟能详的服务，比如 webarchive 这样的数据量，其实背后也只有几个人在维护。前几年面试了国内的一家公司，在机房遍布全球，业务已经发展的比较庞大（上市了）的时候，SRE 团队也只有 10 个人。

另外我比较喜欢问的一个问题是对方关于 AIOps 怎么看。因为我之前搞了两年这个东西，最后得到的结论是，这基本上是个浪费时间、欺骗上层领导的东西。AI 这东西的不可解释性本质上就和运维操作将就因果相违背的。所以经常喜欢问面试官怎么看这个技术，基本上就可以判断靠不靠谱。当然了，这是我个人的职业阴影导致的后遗症，只能代表个人意见。

就说这么多吧，都是一些个人理解，不一定对。写这篇文章感觉自己好像指点江山一样，其实我自己也干了才几年而已，所以本文内容仅供参考。如果有什么问题可以在评论提出，我能回答的话就尽量回答。

The post SRE 的工作介绍 first appeared on 卡瓦邦噶！.

URL Disabler 1.0 免安裝版 - 禁止瀏覽指定網站

Fri, 16 Apr 2021 00:54:00 CST

禁止瀏覽指定網站 - URL Disabler，可以輸入指定的網址讓瀏覽器無法瀏覽該網站，支援Chrome、Firefox、Edge瀏覽器，匯出匯入網址清單、設定軟體開啟密碼、讓瀏覽器無法下載檔案、指定只套用於某個瀏覽器，它不使用修改hosts檔的老方法，所以比較不容易被破解。（阿榮）（下載）官方網站：Sordum.org 軟體性質：免費軟體介面語言：英文系統需求：Windows 10/8.x/7/Vista/XP（32及64位元）關鍵字：URLDisabler, URLDisablerPortable URL Disabler is a Portable (it requires no installation) and freeware to simplify the URL blocking process for Google Chrome , Firefox

分享：个人是怎么学习新知识的

Tue, 09 Apr 2019 22:09:49 CST

挺多童鞋问我是怎么学习新知识的，干脆写篇文章总结一下，希望对大家有所帮助。对照书、技术博客、极客时间等学习的方式我就不说了。

一、早期

在15年及更早，由于知识储备少，基础偏弱，大致采取了如下的步骤：

1.1 入门：找教学视频

了解xx是什么，能解决什么问题。例如个人学习Spring、Struts、Hibernate时，就是找了马士兵老师的视频。

值得一提的是，记笔记非常重要，一是可以形成相对完整的知识体系，二来也能应对面试——面试之前花点时间看看笔记就能很快记忆唤醒。 个人原创学习笔记可关注公众号“IT牧场”，点击资源领取即可获得。

1.2 实战：模拟项目

俗话说，学以致用，为学而学是没有意义的——即使有意义，过段时间也会遗忘。所以个人在掌握基础知识点以及常见用法后，一般都会做个简单的项目。作用主要有几点：

巩固知识点
总结最佳实践
锻炼自己的产品思维

从15年起，个人每年都会定”做一个 Side Project “的KPI——这个项目能承载如上三点作用即可。

15年：基于当时的主流框架捣鼓的快速开发脚手架 Platform（选型较老，已被时代抛弃）；
16年：基于Spring Boot的半成品 CMS （起因是来了个私活儿，于是开工，后来合作崩了，就废弃了）；
17年：基于Spring Cloud的快速开发脚手架与最佳实践总结 Spring Cloud YES ，现已升级到Spring Cloud Greenwich SR1版本；
18年：微信小程序 IT牧场 ，在公众号导航栏点击”资源领取”即可进入，近期开源。

顺便说下，这些项目的内核基本一样，但每次又有优化——每次拷贝老代码前，都再思考一下，看有没有改进的空间——这不是正是”重构”？既是对自己过去代码的重构，也是对自己技术的重新审视。

二、15年后

15年后，由于工作好几年了，知识面、知识深度都达到一定程度——特别是15年初自学Hadoop以及Spark后。

一点趣闻

学习Hadoop和Spark的契机：当时大数据很火，工资很高，于是面向工资编程，想转型大数据。当时正好所在公司高层变动非常频繁，大佬们都忙着政治斗争——倒是爽了我这种小技术经理以及开发兄弟，整整一个半月，没有任何需求。于是投入全日制投入学习，偶尔改改bug。

后来发现，学习Hadoop和Spark是个笑话——因为学完发现在南京找不到大数据岗位——

面试中兴，技术通过了，开17K，部长面也过了，结果卡在学习，说民办本二算本三，不符合他们的学历要求，我也是醉了。

面试鸿信：对方说自己有1T数据，规模在南京排前三。我嘴上不说心里想1T算个毛的大数据……

后来又继续搞Web了。但学习还是有好处的——

大数据知识点杂，有时候还涉及不同语言……这锻炼了自己的知识整合能力；

Hadoop、Spark本身普遍是分布式应用，这为后来玩微服务打下很好的基础；

很多时候，知识点是相通的，如果能探索到本质，会发现很多所谓高大上的东西其实也就是那么回事。

此时，我觉得看视频入门效率太低了，所以调整了下节奏：

2.1 入门：GitHub Demo

看教学视频固然是个很好的方法——因为学习曲线足够低，而且会有导师告诉你怎么用，甚至给你总结好最佳实践。但多数情况下，视频教程对于这个阶段的我，效率已经偏低了。很多视频几十分钟才讲一两个知识点…即使倍速，依然感觉在浪费时间。

于是我采取了Demo驱动的方式学习。以学习 Spring Boot 为例，Spring Boot官方提供了 Spring Boot Samples ，把代码clone下来玩一遍，就能相对系统得了解Spring Boot提供的能力。

TIPS

并非完全放弃教学视频，学习途径的选择是多样的，有时候是二选一，有时是两者配合。

只是进入这个阶段后，个人GitHub Demo驱动相对用得相对更多一些。建议大家做个简单的评估，怎么快怎么来。

2.2 系统学习：官方文档

Demo驱动入门后，我一般会对照官方文档撸一遍，例如学习Spring Cloud时，我把官方文档中的用例都过了一遍。

官方文档带来的好处如下：

一手文档——官方文档永远是最好的文档，书、视频等等本质也是别人通过学习官方文档进行二次创作的；
能体会官方的意图
感知该软件的发展趋势(例如阅读Release Log)
系统、详尽。

很多人可能觉得自己英文水平欠缺，不敢阅读英文文档，这点我只能说硬着头皮上吧，其实坚持一段时间后，你会发现也就那么回事。大部分英文文档还是比较通俗易懂的——再者，现在谷歌翻译质量非常高，进一步降低了阅读英文文档的难度。

我的 Kubernetes开源书，本质就是官方文档翻译(一般看一边翻译) + 个人理解 + 批注。

总的来说，IT行业人才分布也是符合二八定律的——80%的普通人，20%的高手；20%高手里面，80%的普通高手，20%的大佬。我觉得英文不好不是借口，主要还是看你想成为哪个20%——付出和回报是成一定比例的。

另外还有10000小时理论，也可以给大家共勉——要想成为某一领域的精英，必须在这一领域深耕10000小时——如果连英文文档都不敢去碰，怎么可能成为精英？

大道理大家都懂，不再废话了。

闲话

13年个人定了一个原则，就是不找客观借口。因为客观借口只要想找，永远可以找100个。失败是客观事实，但很多失败都是由于主观因素导致的。失败就是失败，首先要有勇气直面。如果连尝试都不敢，就失败了，那真的是可耻到极致的失败。

进入阿里后，我的思想再次发生变化。以前有时候我会觉得由于我没有xx资源，所以我做不了xx事；但现在，我的思想变成因为我要做xx事，所以我需要xx资源，如果没有，那我就去争取；如果没有那我就想办法抢。我离成功还很远，但我会继续努力。技术上成功的难度，对我来说相对低一些，所以我坚持技术路线。

2.3 实战：模拟项目

和之前一样，还是做个简单的项目玩玩，项目能起到练手的目的即可。

2.4 深入：带着问题分析源码

起源于在 焦点科技 的一场面试——焦点科技面试官是对我职业生涯中造成影响的面试官，虽然只有一面之缘，甚至连对方的名字也不知道。

与其说是面试，倒不如说是”切磋”——一般面试，往往是你问我答，OK，NEXT。回答对不对，到不到位，往往不会揭晓答案。

这位面试官很有意思，他会从一个简单的问题逐步深入，并且如果回答不上来，对方会给你很多提示，就像武侠片里师父给徒弟喂招一样——这样面试下来会有所收获，也会了解自己欠缺的地方；更好玩的是，如果你聊到对方不了解的地方，也会问到他懂为止——这其实是考察候选人的沟通能力的常见手法之一，但目前业界又有多少面试官能做到呢？

这次面试给我的启发是：如果广度已经很好，是不是应该深挖呢？

深入，最好的方式就是阅读代码。而为了看代码而看代码，在我看来是浪费生命、浪费时间。所以，我选择在遇到问题时，带着问题分析源码——这里的遇到问题，并不是代码运行报错，或者是项目出异常；而是指对xxx感到好奇，想要了解原理，于是带着问题阅读代码。

2.5 广度：跟进业界动态

个人比较喜欢看科技新闻，大学开始，常年在煎蛋、CNBeta、36氪等科技站上潜水。然而，从15年开始，就一直在995/996，跳到哪儿哪儿加班……时间不够用，必须做出取舍。

经过分析，发现开源动态对自己更有价值。于是坚持每天花10-15分钟刷开源中国的”软件更新咨询”栏目——软件更新栏目相信很多人有所了解，其实就是某某开源软件又发布了新版本的新闻列表。

然而，长期关注至少能获得如下几点信息：

咦？xx软件发布了，这个是啥？解决什么问题的？
咦？xx软件又发布了，这玩意儿挺活跃啊！
咦？xx评论挺多的，看来很快会流行起来。

长期关注的收益：

了解行业动态
增进知识广度
培养行业敏感性

我在15年玩Spring Cloud、16年玩Docker、17年玩Kubernetes，时间基本都在业界流行之前。之所以有这种行业敏感性，和长期刷开源中国是分不开的。

TIPS

再安利就变成开源中国软文了……相信我，开源中国没有给我钱……

三、16年后

3.1 写博客：让别人也能懂

16年，因为一些契机，从开发转型成为架构师。角色的转变，带来的是思考视角的转变。之前做技术经理时，名下只有四五个人，多数问题口头交流就OK了；但成为架构师后，负责的面变大了，有时得和几十个人沟通，而很多沟通是重复的。

此时，我意识到，不如把大家常见问题总结总结，写成手把手的文档——

手把手上手系列
手把手解决问题系列
血的教训系列……

再后来，发现写Spring Cloud开源书、博客、实体书……

写作本身也是总结的过程，而且不仅要自己懂，还要想办法让别人也能看懂。

可能是写手把手系列多了，所以我的文章一直也是手把手、附具体步骤、配详细代码，原理、源码分析写得相对少一些，这点也被一些人诟病。个人对博客的定位，主要是引导新手，其次是个人心得总结。如果人家已经入门了，还需要到处找文章吗？自己研究研究就OK了。

那些喜欢看源码解读的”高手”，有多少是真高手，有多少是伪高手？我相信有源码阅读经验的，都不会觉得阅读源码是一件高大上的事情——多数情况下，看懂开源软件源码真的比看懂你所在项目的遗留代码简单多了！

趣闻

18年在华为面试，和面试官聊到Zuul相关源码。大致问题是：聊聊Zuul ErrorFilter存在的Bug。这个Bug其实在Camden已经修复了，但是我好说歹说面试官都不信。结果再一打听，原来面试官看到《Spring Cloud微服务实战》是这么写的——这本著作是基于Spring Cloud Brixton撰写的，该版本确实有Bug，所以作者非常贴心地给出了解决方案，却被这位面试官拿来做考察一个人对Spring Cloud是否深入的尺子。

四、写在最后

以上是我历年学习方法的分享。其实总结起来就一句话：我不够聪明，但我会死磕，逐步积累；我不找客观原因，硬上。

中间穿插了很多例子，文章可能有点碎……Anyway，希望对大家有用。

实用技巧：教你如何在没有网络的Linux机器上快速安装软件

Sat, 22 Dec 2018 03:11:49 CST

相信很多人遇到过这样的问题：

你需要在公司的一台服务器上安装xxx软件，例如vsftpd；
该服务器无法连接公网；
这台服务器很可能是一个最简安装的Linux（意味着该机器可能有很多常见的软件依赖缺失），你也搞不清楚究竟是不是最简安装的，只能用 uname -a 或者 /etc/redhat-release 看到发行版本；

于是，你应该怎么安装想要的软件？

下面以带有浓重的感情色彩，总结三种方案。

TIPS：本文以CentOS 7为例，探讨几种安装方式。其他发行版，可参见拓展阅读给出的方案。

最土但最极客的方法

一些人可能会下载源码，然后上传到服务器上编译安装。编译有问题会报错，一般要么是缺包（比较多），要么是冲突（相对较少）。那就分析日志，缺包就找包，冲突就换包；找到包后再上传到服务器上搞，周而复始，直到完成。

个人对这种做法非常不喜欢——

效率太差；
操作复杂繁琐，中间可能会中断若干次。环节越多，出现失误的可能性越大；
对于服务器，没有十足的把握谁敢这么操作……
对于不同版本的CentOS / RedHat，很多依赖的包名都变了……有的包还挺难找的……

我14年前后，在一台无网络的机器上编译安装过MySQL（公司的测试环境，可以随便玩），花了小半天……感受是：这种方式只有脾气好、并且富有极客精神、不怕苦不怕累，还无敌有信心不弄坏公司服务器，并且还得还闲的蛋疼的大神才能hold住，对于我等凡人，恐怕是不大适用的。

PS. 可能有人说高手不都应该编译安装吗？我个人觉得这种顶多也就算个伪高手——真正的高手看重的是解决方法是否有效，才不care你是一行命令自动安装，还是用18页命令编译安装……

不那么土也不那么极客的方法

这种方案应该是一半以上童鞋都会选择的——RPM包安装方式。先找到相关的RPM包，然后用 rpm -ivh rpm包名 安装。

RPM可在 http://rpmfind.net/ 上找到，我是说大部分。

一般来讲，该方案问可以很好的解决问题，但极端场景下也会跪。原因依然是缺包……

RPM并不一定包含软件所有的依赖，有时候可能一个软件依赖了若干个RPM，你得通通找到，然后一起安装……

个人最喜欢也最简单的方法

借助 yum-plugin-downloadonly 。这是个人最喜欢的方法，简单粗暴高效。

下面附带完整的安装步骤：

准备1台和服务器 最简安装了 同版本Linux的机器，记为机器B， 机器B需要能联网 。

TIPS：可以是实体机、虚拟机或者Docker容器，看你的喜好。

个人建议用Docker准备，一分钟就可以准备好了。Docker相关课程可在我的公众号，或者博客搜索一下，有全套系列。
远程上机器B。

在机器B上执行如下命令：

       # 安装yum-plugin-downloadonly插件
       yum install -y yum-plugin-downloadonly
       # 把vsftpd换成你想要的包名
       yum install --downloadonly <vsftpd>

下载的软件在：
1
/var/cache/yum/x86_64/7/base/packages/
该目录里会存放你想安装的软件所需要的所有RPM包。
将所有RPM包拷贝到服务器上安装既可。如果安装过程中提示xxx已安装是否需要覆盖，全部选否。

是不是非常简单？应该也有很多童鞋知道这种方法的，本身也不是什么秘密。但就我的感知，很可能更多的人不知道，好几个人问我了，所以分享一下。

其他方法

Yumdownloader ，用法和 yum-plugin-downloadonly 大同小异。用本行高亮的部分作为关键词自行搜索吧。

拓展阅读

怎样在 CentOS 里下载 RPM 包及其所有依赖包: https://blog.csdn.net/linuxnews/article/details/53244315

Ubuntu其实也有类似的命令 apt-get install -d --reinstall 包名 ，这样既可只下载包，而不安装包了，然后拷贝到无网络的机器上安装既可。

apt一键下载所有依赖的包： https://blog.csdn.net/junbujianwpl/article/details/52811153

分享我司基于K8s & Spring Cloud的私有云技术选型！

Tue, 11 Dec 2018 01:03:26 CST

最近有同事问到我基于K8s & Spring Cloud的PaaS云平台的相关问题，正好之前在 卓望数码 时专门做这个的。考虑到技术选型本身并不涉及业务，也不涉及商业机密，索性整理一下，分享出来。

注1：考虑到前公司的利益，下表列出的个别项目公司并未实际使用，又或者实际使用了，表格里故意写的未使用。再次强调，故意混淆，保障前东家的利益。

注2：感谢前东家 卓望数码 。

平台级

作用	名称	备注
平台	Kubernetes	你懂的
服务容错、断路器、	istio、linkerd	我们都没有使用（我们用Spring Cloud，Spring Cloud也有类似实现），当时istio还没有发布1.0，现已经可以用于生产；Linkerd我们当时觉得第一代上了也会被取代……
存储	Ceph、GlusterFS	我们用GlusterFS
CI/CD	Jenkins	我们只用来构建镜像，并push到私有Docker Registry
发布平台	Spinnaker	是在Kubernetes上功能最强的发布平台，Google/Netflix等开源，用这个可以不使用Jenkins了，建议调研一下。
Docker Registry	Docker Registry/Habor/Nexus	我们用Nexus 3，主要是为了同时管理Docker镜像和Maven依赖。Habor也非常不错，国产（虽然公司是外企）骄傲！
包管理	Helm	我们当时没有使用，时间占主要因素，现在已经在CNCF孵化了，很有前景。

监控

监控维度	工具
容器实例监控	Heapster+Grafana+InfluxDB
应用实例监控	Java应用本身的监控：Spring Boot Actuator + Spring Boot Admin GC监控与分析：gceasy、fastthread、gcplot等
分布式应用监控/APM	调用链监控：Zipkin、PinPoint、SkyWalking等，你猜我们用的啥？
中间件/基础组件监控	MQ/MQ监控：Kafka + Kafka Manager 缓存/缓存监控：Redis + RedisStat/RedisLive 数据库/数据库监控：MySQL + MyCAT
日志监控	Fluentd + Elasticsearch + Kibana

代码质量与管理

名称	作用
GitLab	代码管理
SonarQube	质量管理平台，使用非常简单，可以扫描出代码中的脆弱点、Bug等。并可整合Findbugs、PMD、PMD等工具增强使用。

svn 钩子开启

Mon, 24 Apr 2017 17:24:33 CST

svn 钩子开启

背景: 公司的Svn很多人在用，有不少人在作修改后不添加注释，所以需要强制用户填写注释。操作：

重命名svn主目录中hooks的pre-commit.tmpl文件为pre-commit，并添加可执行权限

  mv pre-commit.tmpl pre-commit
chmod u+x pre-commit

编辑pre-commit文件

  export LANG="zh_CN.UTF-8"
REPOS="$1"
TXN="$2"

# Make sure that the log message contains some text.
SVNLOOK=/usr/bin/svnlook
#$SVNLOOK log -t "$TXN" "$REPOS" | \
# grep "[a-zA-Z0-9]" > /dev/null || exit 1

commit_type=$(svnlook changed -t "$TXN" "$REPOS")
#以下后缀可以不填写注释
except_list=".txt,.docx,.doc,.xls,.xlsx,.ppt,/"
num=0
for i in $(echo -e "$except_list" |sed "s/,/\n/g")
do
    sum=$(echo -e "$commit_type" |grep "$i$" |wc -l)
    if test[ $sum -ne 0 ];then
        num=$(expr $num + 1 )
    fi
done
total=$(echo -e "$commit_type" |wc -l)

if test[ $num -eq $total ];then
    exit 0
fi

$SVNLOOK log -t "$TXN" "$REPOS" > /tmp/aaa.txt

#强制用户提交注释,注释格式要求:bug/task+数字(任务数字编号)+注释(大于10)
TEMP_LENGTH=`$SVNLOOK log -t "$TXN" "$REPOS"|sed 's/\s*$//g'|sed 's/^\s*//g'| wc --chars` # 获取字符数量(包括换行符)
TEMP_LINE=`$SVNLOOK log -t "$TXN" "$REPOS"| wc --lines` # 统计换行符
LOGMSG_LENGTH=`expr $TEMP_LENGTH - $TEMP_LINE` # 真实字符数量
task=$( $SVNLOOK log -t "$TXN" "$REPOS" |grep "^task\-[0-9]*[0-9]\-" |wc -l )
bug=$( $SVNLOOK log -t "$TXN" "$REPOS" |grep "^bug\-[0-9]*[0-9]\-" |wc -l )
emrg=$( $SVNLOOK log -t "$TXN" "$REPOS" |grep "^emrg\-[0-9]*[0-9]\-" |wc -l )
getlaststring=$($SVNLOOK log -t "$TXN" "$REPOS"|grep -o "^task\-[0-9]*[0-9]\-\|^bug\-[0-9]*[0-9]\-\|^emrg\-[0-9]*[0-9]\-")
content=$($SVNLOOK log -t "$TXN" "$REPOS"|sed 's/\s*$//g'|sed 's/^\s*//g')

if test[ $LOGMSG_LENGTH -eq 0 ];then
    echo "【注释】$content" 1>&2
    echo "【注意】注释不能为空,请重新填写注释!!!" 1>&2
    echo "【格式】:bug/task/emrg-数字任务编号-注释(大于10)" 1>&2
    exit 1
fi

if test[ $task -eq 0 && $bug -eq 0 && $emrg -eq 0 ];then
    echo "【注释】$content" 1>&2
    echo "【注意】注释必须以bug或者task开头,后面加-和数字编号,请重新填写注释!!!" 1>&2
    echo "【格式】:bug/task/emrg-数字任务编号-注释(大于10)" 1>&2
    exit 1
fi

commemt=$($SVNLOOK log -t "$TXN" "$REPOS"|sed 's/\s*$//g'|sed 's/^\s*//g'|sed "s/^$getlaststring//g"| wc --chars)
commemt_line=$($SVNLOOK log -t "$TXN" "$REPOS" |sed "s/^$getlaststring//g"|wc --lines)
commemt_length=$( expr $commemt - $commemt_line)

if test "$commemt_length" -lt 10 ;
then
    echo "【注释】$content" 1>&2
    echo "【注意】注释必须超过10个字符,请重新填写注释!!!" 1>&2
    echo "【格式】:bug/task/emrg-数字任务编号-注释(大于10)" 1>&2
    exit 1
fi


# Check that the author of this commit has the rights to perform
# the commit on the files and directories being modified.
#commit-access-control.pl "$REPOS" "$TXN" commit-access-control.cfg || exit 1

# All checks passed, so allow the commit.
exit

一、问题

  * pre-commit等钩子有做一些检查，如果有问题就echo错误信息，但出错信息是中文的，svn客户端无法显示，提示如下

Error output could not be translated from the native locale to UTF-8.

我们尝试过以下方法，但都没有解决

修改pre-commit的编码，修改LANG

  export LANG=zh_CN.UTF-8
export LC_ALL=zh_CN.UTF-8

修改Apache的编码

  AddDefaultCharset UTF-8

采用http发布，而不是https

结论：网上的解决方案只对 svn://这种直接用svnserve发布出来的仓库才有效

二、解决方案

Subversion 1.8特性

SVNUseUTF8 On

它的作用就是使得Apache的mod_dav_svn模块，在和pre-commit等钩子通讯的时候，使用utf-8编码，可以参考mod_dav_svn

升级

我们系统是CentOS 6.2，比较简单，有个第三方，走了Subversion 1.8的rpm包，yum即可，主要是更新了2个rpm包

  * subversion-1.8.15-1.x86_64
* mod_dav_svn-1.8.15-1.x86_64

具体升级操作

  cat > /etc/yum.repos.d/wandisco-svn.repo <<EOF

[WandiscoSVN]

name=Wandisco SVN Repo

baseurl=http://opensource.wandisco.com/centos/6/svn-1.8/RPMS/\$basearch/

enabled=1

gpgcheck=0

EOF



yum install subversion -y

修改httpd.conf并重启httpd

  <IfModule mod_dav_fs.c>

    # Location of the WebDAV lock database.

    DAVLockDB /var/lib/dav/lockdb

    SVNUseUTF8 On

</IfModule>

/etc/init.d/httpd graceful

升级后的测试

需要做些测试，确保升级后不会有问题，测试列表如下

  * commit
* update
* log
* merge
* copy签出版本

注意问题:

服务器版本是1.8，如果客户端是1.6，则只能checkout，不能update，1.7没有问题，建议客户端至少1.8

从Excel到微服务

Sat, 17 Jun 2017 22:44:06 CST

Excel很老，Excel很土，Excel一点也不sexy；微服务新，微服务很潮门，微服务很高大上。那么，Excel和微服务有什么关系？

上个月看了篇文章，The Unbunlding of Excel。作者认为，对于初创公司（尤其是非“纯IT”初创公司）来说，Excel几乎包办各种工作。想要计算？请用Excel。想做轻量级的CRM，可用Excel。建立财务分析模型？还是用Excel。简单的项目管理？当然Excel。数据分析总揽图？仍然是Excel。执行简单的ETL任务？Excel再合适不过了。

Excel真的这么能干吗？从逻辑上说，它是成立的。首先公司里很多业务都是基于数据的，其原型都是对表格的操作，Excel“天生”就是表格。其次，Excel提供了足够弱又足够强的“编程能力”，Excel中的VBA、透视表等等功能对于强大的编程语言来说或许不值一提，但许多对编程语言望而却步的人却能把这些功能运用得无比纯熟，玩出的花样让很多程序员也叹为观止。

更重要的是，初创公司的业务往往是不确定的，业务领域需要探索，业务规则也需要不断修订。Excel虽然没有量身定制的系统那么完善，但成本相当低廉。对初创公司来说，除非自己养着非常厉害的开发团队，系统又做得足够高质量足够灵活，一面猛改一面还保持稳定，否则即便“上系统”，也经常被系统困住手脚，业务反而受到拖累。

如果你觉得这只是“逻辑上”的分析，我还可以给出更现实的例子。

如今很多公司都知道要有CRM（客户关系管理）系统，来处理和汇总与客户之间的问题。业务还没开展，CRM先得买一套或者开发一套，这已经成了流行的思维定势。但是，买来或者开发的CRM，未必能很好满足自己的业务需求，因此踩坑的例子数不胜数。

朋友的一家公司，一开始根本没有上CRM，只要求客服每人每天用Excel把回答的问题记下来，每天晚上指定专人汇总，第二天早上把汇总和更新之后最新的Excel通过邮件下发给所有客服，回答问题的时候就在这张表里用Ctrl + F来寻找关键词。这样的做法虽然看起来很累很烦，却足够简单有效。既不用担心系统死掉大家都干不了活，也不用担心问题分类设定不合理无法录入或者数据格式变化导致的历史数据清洗成本。

等这套流程真正跑顺稳定了，公司业务也足够大了，有时间有资本把已经摸索的客服管理的经验和流程固化到系统里，CRM系统开发顺理成章，上线到投入使用相当自然。

我还见过一家电商公司，因为赶上了风口，业务发展极其迅猛。于是公司也马上遇到了问题，创始人都是做互联网的出身，对实业并没有多么丰富的经验，多地仓库的管理成了老大难，库存经常乱套了。

怎么办？虽然自己有一支小的开发团队，但日常业务已经足够他们忙的了，而且仓储是个专门的领域，即便没做过，专门去看看也知道水很深，何况仓库运营的规则和办法还在不断优化，这时候要做出一套好用的仓储系统，几乎是痴人说梦。然而每次出问题，很多基层员工都会抱怨，要是有系统就好了。

创始团队想到的办法就是Excel，不管仓储规则怎么千变万化，基本的库存管理，无非是入库、出库、盘库等几个动作，数据格式是相对固定的。那么，每个仓库每天干完活，再忙再累再晚，也要把仓储信息按照约定的Excel模版回传到总部，由专人统计合并。这工作说起来简单，做起来可让人叫苦连天，尤其是还有些仓库分布在海外有时差，每天光是统计合并这些数据就得一两天。

既然老大发了话，下面的人有抱怨也不敢发出来，只能老老实实执行。整套流程两三个礼拜，日常的操作基本都不会出问题，要完善操作流程时，也大概知道了该怎么修改表格。就这样边录边改，磨合了大半年，终于把流程基本定下来了。这时候再安排产品经理、项目经理、程序员进场，一看日常用的Excel，数据项、数据项之间的关联清清楚楚，不清楚的地方问问操作人员也立刻可以得到解答。这时候再安排开发仓储管理系统，基本不存在什么领域知识难题，更像是顺水推舟的事情。

仔细观察这两个例子，你会发现，它们的本质是一样的，即在对问题域还不够了解、问题解法还没有彻底明晰之前，需要一种具有一定规范性同时低成本的手段，一方面对现有操作进行约束，另一方面能持续探索问题、完善已有方案。这时候，他们选择了Excel。

本来我看完这篇讲Excel的文章就准备谈点感想，巧合的是，后来又看到一篇“神似”的文章，You are not Google。作者强调的是，别盲目崇拜那些大公司吹得神乎其神的技术，真正重要的是理解你的问题。这个主旨，和上面文章里对Excel的“吹捧“其实是一致的。

你知道GFS和Map/Reduce，但是你知道它们是为了解决什么问题的吗？是为了计算、存储、索引所有的网页（那个时候大概有8000万）。你知道SOA，但是你知道亚马逊什么时候上的SOA吗？那时候亚马逊已经有7800名雇员，年营业额超过30亿美元了。你只知道数据库集群、NoSQL，但是你知道吗？Stack Exchange在2016年，面对2亿的日访问量，只有4台SQLServer……

好了，现在我要回到题目，说起“微服务”了。

微服务很新，微服务很潮，微服务很高大上。我在面试架构师的时候，很多候选人说到微服务，都可以侃侃而谈，各种新鲜的名词、概念、框架止不住地蹦出来，却没法回答几个问题：为什么微服务会崛起？什么时候应当实行微服务？实行微服务要注意什么？甚至，连微服务与SOA的关系是什么都搞不清楚。

要知道，架构师并不是“框架和解决方案推广落地人员”，他是需要做决策的，软件开发中，架构决策对系统的影响往往是至关重要的，一旦出现问题，后果可能相当严重。所以，合格的架构师对于微服务，不但需要了解现成的方案和概念，更应该真正的问题是什么，决策的依据是什么，然后才能知道，自己的决策是否合理。

在我看来，微服务对SOA既是延续也是更新。在我们谈论SOA的时候，谈得更多的是一种设计理念，它要求脱离软件本身的限制，从抽象的“服务”角度来进行思考和设计。从此，我们可以在更高更抽象的层面上来思考如何用软件解决问题，不再时时处处受到技术的掣肘。然而，SOA谈论了多年，一直没有看到具体的、公认的、合理的落地案例。

许多谈SOA的书里都会讲到一个概念：ESB。希望有一天，软件服务也可以像硬件服务那样，有一条通用的总线，然后各种服务只需要简单接入就可以了。但是这或许只是一个美丽的梦想，真正投入使用的ESB其实相当少。

微服务的兴起，很大程度上对应着我们在探索未知领域、探索未知问题脚步。我们无法全知全能地知道，系统的什么部分、哪个环节，在什么时候会成为障碍或瓶颈，但是，我们又必须迅速地发现这些障碍或瓶颈，解决它们，同时保证整个系统的稳定。把系统拆分为一个个微服务，正是为了解决这样的问题，它让我们可以聚焦在具体部分和环节上，又限制了复杂性，避免了“牵一发而动全身”的尴尬。

仔细思考就会发现，微服务的兴起，也是对ESB思路的颠覆。ESB强调的是“重通讯轻终端”，微服务强调的则是“重终端轻通讯”，数据通讯一般只是通过简单的HTTP进行，终端对于通讯总线并没有特别强的业务依赖。这样确实降低了耦合性，但也对终端提出了更高的要求。

以前大家只习惯于写一点业务逻辑代码，生成几个类库，放到巨大的单体系统里就可以放心了。进行微服务改造之后，你的这点业务逻辑代码只是服务的核心，既然名曰“服务”，就得五脏俱全，既然名曰“微服务”，就得螺蛳壳里做道场。

换句话说，服务必须能独立部署、独立维护、方便扩展。你得在服务的边界清晰和技术限制之间做出权衡，你得搭建完整的监控，你得考虑高可用性，你得选择通讯机制，你得分析负载压力，你还得仔细规划容量…… 身为架构师，一门心思考虑分家，一味鼓吹分家的各种好处，绝对是不称职的：分家过日子当然潇洒，但自己当家却不知道柴米油盐贵，这是绝对要饿死的。

最后讲个有意思的事情，这些年我有好几个技术很好对微服务理解很深刻的朋友，去了创业公司首先做的事情往往都是“技术的倒退”：就这十来个人、七八条枪，还折腾什么微服务？快别扯淡了！

附：原文链接
The Unbunlding of Excel
You are not Google

微服务与架构师

Fri, 11 Nov 2016 17:47:37 CST

因为工作的关系，最近面试了很多软件架构师，遗憾的是真正能录用的很少。很多候选人有多年的工作经验，常见的框架也玩得很溜。然而最擅长的是“用既定的技术方案去解决特定的问题”，如果遇到的问题没有严格对应的现成框架，就比较吃力。这样的技能水平或许适合某些行业，但很遗憾不符合我们的要求。

软件架构师到底应该做什么，又为什么这么难做好，这都是近来的热门问题，我也一直在和朋友们讨论。正巧，最近我看完了新鲜出炉的《微服务设计》，所以大概可以谈谈自己的看法了。因为这类问题比较抽象，也没有统一答案，我努力尝试把思路整理清楚，把表达变得流畅。最终有没有讲清楚，说的对不对，欢迎大家给我留言。

今天看来，传统的软件开发（尤其是应用型软件开发）其实是相对简单的。软件运行在基本可靠的单机环境下：CPU提供计算能力，内存提供动态存储，总线提供数据传输，硬盘提供永久存储。这些概念稳定而直观，程序员要完成的，就是调用和组装编程语言提供的各种功能，来满足现实的需求。相比应用程序员良莠不齐的开发水平，无论是操作系统还是硬件环境，都是来自大公司的工业级别的产品，是值得信赖的。

如果把程序要完成的功能比作个人，软件运行的环境比作房屋，那么房屋虽小，却是值得信赖的。对个人来说，只要进去了房屋里，就有相对稳定的环境，相比野外生存就是巨大的进步。当然，如果遇到意外情况，在野外可能生存机会大一点，在房屋里只能与房子“一损俱损”了。不过，通常来看这不要紧。

随着计算机要解决问题日趋复杂，出现了可复用的类库。它们把重复的功能包装起来，只要直接拿来就可以使用。回到房子的比喻，这些东西就好像标准化制作的家用电器，你搬回去、看懂说明书、用起来，就可以大大提升自己的效率。

上面说的是软件内部的进化，软件外部运行模型仍然相对简单——无论要解决什么任务，各种逻辑和资源都是处在同一个运行时（runtime），或者能够方便可靠访问的运行时当中。如果需要提升性能，除去软件本身的优化，就是升级硬件。如果我们需要更快的计算速度，就必须升级CPU；如果我们需要更多的动态存储，就必须升级内存…… 虽然升级需要停机，但是升级之后，性能提高了，运行环境的稳定可靠却不受影响。回到房屋的比喻，在这种思路下，房子还是原来的房子，只是建造得越来越高级，越来越稳定。

即便业界提出了N层模型，整体的复杂度提升也有限。这种划分往往并不是严格按照业务责任，还考虑了实现特性，而且层与层之间的接口仍然能依赖外部环境保持稳定可靠。比如常见的三层模型，表现层-业务逻辑层-数据库层，表现层与业务逻辑层之间往往是函数调用，业务层与数据库层之间的通常是通过安全稳定的内网连接，数据库则是配置很好的机器保证高可用性。回到房屋的比喻，这种思路很像花重金建造几栋紧密相连的专用房屋，各自对应不同的用途。如果外界环境变化不大，这种设计确实很稳定，但也很不灵活。

随着互联网的飞速发展，程序要解决的问题的复杂度也在飞速，原有的思维和范式，既要考虑业务，又要考虑实现，应对起来已经非常吃力了。所以，SOA（面向服务的架构）的概念应运而生。SOA基本脱离了技术实现的细节，引导开发人员从业务和抽象的“服务”角度来看待系统。与传统复用只考虑静态的代码和类库不同，SOA复用的则是动态的运行着的服务。

以上两点，都是SOA相对传统软件开发思想的巨大进步。可惜的是，大多数SOA的学说更倾向于理论和概念的层面，服务的“粒度”究竟定在哪个层级，服务如何落地保证可用性…… 这些问题始终没有取得广泛的共识和规范，对于软件所依赖的环境，SOA也很少涉及，但软件的运行是离不开外部环境的。所以SOA的学说虽然热门，但真正做到了、做好了的例子非常有限。

回到房屋的比喻，SOA不太关心每栋房子到底干什么，只是从逻辑上做个大致的区分：这片房子分给商人，那片房子分给农民，另一个片区的房子分给工人…… 但是SOA并不会具体地规定每个区域里应当安排多少房子，这些房子应当如何建造，如何组合，所以区域里很可能有混乱。

技术继续发展，尤其是移动互联网的兴起，极大地增加了软件所要解决问题的复杂度。从内部来说，性能的增长已经改变了方向，无论CPU还是内存，性能的增长都不再来源于单纯部件的提高，而更多来自多个普通部件的协同工作。如果说传统的性能提高是从纵向上考虑，现在则是从横向上考虑，承载计算能力的不再是“一颗高运算速度的CPU”，保存动态数据的也不再是“一片大容量内存”。玩法变了，程序的思维和编写范式也需要随之进行调整。

从外部来说，性能提升而运行环境仍然稳定的好事不复存在，运行环境日益复杂，可靠性也随之下降，已经没有哪家软件和硬件厂商能为系统提供足够可靠的运行环境。这种外部的挑战很难和以前一样依靠外部供应商来解决：廉价服务节点莫名崩溃很可能是家常便饭，如果网络完全要求节点自身质量过硬以提供高可用性，不但代价高昂，而且违背了网络设计“容忍故障”的初衷；大量程序调用现在通过网络而不是本地进行时进行，几乎无处不在的超时限制会逼迫大家采用异步调用，传输速度和稳定性也会受到极大限制——分布式系统设计中的重大谬误之一就是认为“网络是可靠的”。

更糟糕的是，SOA未能解决的粒度问题变得要紧起来。传统的软件系统大致都有规格说明书，在设计时就要考虑每个子系统的承载能力，而且这些能力大致是彼此协调彼此关联的，系统运行时应当保证压力不超过设计规格。但是现在，业务的飞速发展很可能把段时间内就压力集中到单个服务甚至其中的少数功能上，跨服务的功能很可能又需要迅速组合成新的服务，而这种变化是事先根本无法预料的，很容易暴露出服务定义的粒度问题。再者，从整体上考虑，每个服务既要保证自己的稳定，又要相对隔离以限制故障的影响，同时还要适度容忍其它服务的不稳定，最终才能从总体上保证系统的稳定。这，也是对传统开发思维的一大挑战。

在这种局面下，“微服务”应运而生了。承接SOA的概念，它把系统按照业务责任划分为彼此独立的多个服务，既保证了概念的清晰和自洽，又保证了系统的灵活性、伸缩性。面对杂乱不可靠的现实，它又从实现上注重每个服务的自治性，也就是能独立部署，具备自动化、可观察、故障隔离、自动恢复等特性，由此提供高可用保障。同时，微服务又抛弃了SOA中的很多概念，比如难以落地的ESB、UDDI等等。

在SOA尚且没有完整落地的时候，对它有继承有更新有颠覆的“微服务”，极大增加了开发人员的挑战。首先，服务要拆的足够小，又不至于太小，这样才能保证伸缩性并隔离故障；其次，不能因为服务“小”就降低保障级别，维护一堆“小服务”的保障级别，这是极其麻烦的事情；再次，要做到上面这一切，无论是从理论学说上还是从可依赖的软硬件系统上，都没有现成的低成本的解决方案；最后，因为维护的是动态的“服务”，传统静态的“代码所有权”和“机器所有权”的划分不再有效，它们已经融合为统一的“服务所有权”，它属于开发人员、运维人员以及所有相关人员的共同体，这又会带来团队配合与分工的挑战。

回到房屋的比喻，其实这个比喻此时已经完全不合适了。现在的系统更像高度复杂的城市，而不是单独的房屋，所以架构师也不像建筑设计师，而更像城市规划师，他的职责是对城市进行规划，确定每个区域应该做的事情，这些区域应当达到统一的规范要求，又具有随时扩张或缩减的灵活性；同时，他还应当保证这种划分适合对应的专业人员在对应区域工作。

明白了这一点，就可以明白版本管理、持续集成、自动化测试、自动化发布、服务治理、详尽监控等等“磨刀工夫”的价值——没有这些工作，就谈不上微服务的质量和保障级别，也就无法驾驭微服务的体系。

由此，也很容易明白架构师在这个时代要面对的挑战。一方面，他没有现成的足够强大的集成工具，只能靠一堆“稀松平常”的工具组装出整体可靠的系统；另一方面，他又要深入理解业务，把业务拆散成边界清晰的概念，以高内聚低耦合的服务分而治之，还必须考虑到实现的限制——“高内聚低耦合”的原则人人都知道，如果没有可靠的分布式事务管理机制，就不得不把并非“高内聚”的模块聚合起来，但你又要担心业务边界模糊的风险；RESTful固然优雅，但有时候又不得不使用RPC通讯，所以你又要提防RPC带来的强绑定、客户端服务器端同步更新等很多问题……

这一切设计、权衡、决策，并没有成型的理论和学说可以依靠，通常只能完全依赖架构师的经验、理解、思考。所以困难很大，风险也很大，如果做得好，收益也是非凡的。而这，恰恰是架构师的价值所在。

创业公司需要基础架构团队吗？[极牛编辑修改版]

Wed, 09 Mar 2016 10:52:04 CST

关于「真格 · 极牛技术分享」

「真格 · 极牛技术分享」- 极牛为真格基金投资公司打造的定期技术分享交流活动，采用“微信群分享 + 线下沙龙”的方式，分享和讨论新技术优秀应用实践、知名创业项目架构分析、技术工具评测和分析等技术话题。极牛愿与真格基金投资公司一起努力，共同提高中国创业技术含金量，打造一流技术能力。

关于唐福林

雪球首席架构师，前微博技术委员会成员，微博平台架构师；Java 后端程序员，已经不写 PHP，C 和 Pascal 很多年；ACM/ICPC 和 NIO 比赛深度参与者。

技术交流欢迎在微博上关注我 @唐福林

炒股，理财，资产管理，量化交易相关，欢迎在雪球关注我 @唐福林 xueqiu.com/fulin

近期，在极牛举办的「真格 · 极牛技术分享」上，唐福林集中分享了在微博和雪球做架构师和带架构团队的经历，并且对创业公司是否需要基础架构团队这个问题给出了深度解答。以下是唐福林分享文字内容。

1. 基础架构团队到底做些什么

要解答创业公司到底需不需要基础架构团队这个问题，首先我们来来聊一聊基础架构团队的职能是什么。

基础架构团队到底做些什么？

为实现业务功能：技术选型，决策
为了更好的实现业务功能：引入新技术/做法，提供内部支持
解决历史遗留的技术债务：发现问题，找出解决方案，并推动解决
业务开发与线上运维中间有很宽的“三不管”地带需要填充，还需要坚实的基础设施支持

架构组工作的特点有哪些？

基础架构团队存在的价值是解决非业务逻辑的技术相关问题，没有产品或运营驱动
从技术角度看，每个问题都有很多种解决办法
这些问题一般都是重要不紧急，短期内不解决也不会崩
解决这些问题带来的价值对于非技术人员（特别是老板）不是很直观

2. 基础架构团队是创业公司技术发展的必然产物

在“社会主义初级阶段”，还不需要独立的基础架构组。比如，一开始，1~3 人小团队team leader 自己做决策，出问题 team leader 解决，用啥语言？cache？db？上不上云？这些问题直接导致了团队后续技术力量的升级。

到了Demo阶段，也就是3~5 人小团队，这时候应该有个架构师了，技术问题就会留给架构师解决，比如用啥框架？第三方库怎么选择？

后期发展到上线阶段，大概是5~10 人小团队，可以分组了，每个组都要有一个架构师， 解决的问题就变成相互之间怎么配合？怎么保持公共基础部分的一致性？怎么解决互相依赖问题？

做好了前期的准备工作，到了公司的发展阶段，技术团队变成10~30 人，就应该有专人负责基础架构了，主要负责业务无关的技术基础设施维护，服务化框架以及治理，上线的流程等一系列问题。

如果业务到了爆发阶段，有了30~100 人的团队，就应该设置专门的基础架构团队了，开始负责技术基础设施及服务，提供内部的 PaaS，或者 SaaS等。

最后到了100+人的“高级阶段”–平台阶段，应该设置平台团队了，将公司的主体核心业务功能做成服务，供商业化或创新业务使用。在平台内部设置架构组，提供高附加值的技术支撑，异地多机房部署，大规模虚拟化平台这些宏观上的部署和组建就要开始认真思索了。

3，基础架构能做的再好一点吗？

2012年，我在微博的个人的职责从工程师转变成了架构组的组长，最重要的职责从自己写代码，转变成了“如何创造条件让团队成员更好的写代码”。这一年，微博平台壮大，职责划分逐渐明晰，我开始真正从管理领导层面思考怎么才能让基础架构做的更好一点。

首先是怎么做的问题，最重要的要求是要主动多想，没有外力驱动的时候要自我驱动，提高主动性，寻求目标，进行自我评价， 没有外力驱动，没人外人评价，我们很容易陷入一种自我满足的困境 ：看，我做好了，我做的很牛，这回肯定可以评个优，年底多发奖金了吧。

而实际上，大部分时候，我们做的都还不够好。这里的好有两层意思：从技术本身的角度评价，跟周边公司横向比较等等；另外，就是你做的东西有没有真正的完全解决问题，不是从做的人的角度看，而是从碰到问题需要解决的人的角度看，比如业务开发团队是不是觉得好用，是不是觉得这正是他们想要的？

其次在做事的态度上，要力往一处使，因为解决一个技术问题可能有很多种办法，基础架构团队的职责就是找出一种办法，并推行到所有适合的场合，在这个取其精华去其糟粕的过程中一定要见识一起改进，禁止另起炉灶。

做任何事都要讲求方式，做基础架构的方式就是用数据说话，找到合适的评价数据指标，比如写了一个牛B的rpc框架？到底好不好，好在哪里？

另外很重要的是对于选人的要求，要能耐得住寂寞，尤其是在业务爆发式增长时，基础架构团队更需要耐得住寂寞。组建一支牛B的基础架构团队，让业务开发人员跳槽到另外一家公司以后，还会想起你们的好。所有从 Google 出来的人，都会怀念 G 家的内部基础设施。

对创业公司来说，基础架构极其重要，尤其是小的创业团队应尽早安排一个“架构师”的职位，招聘或内部培养一个架构师，如果发现一个架构师忙不过来，那就是时候扩大成一个基础架构团队了。

每日站会、代码审查、结对编程之开源中国实践

Tue, 22 Mar 2016 19:00:23 CST

在我来到开源中国之后，尝试将每日站会、代码审查、结对编程这三种编程实践带入团队。而这个过程，我个人觉得是一项非常宝贵的体验。我觉得可以拿出来和大家分享。

先介绍下目前我们团队的结构：3名Java开发，1名前端，2名实习。

以下我不会详细介绍它们分别是什么，也无意讨论它们有什么好处坏处，本文侧重分享在实践它们的过程可能遇到的问题，以及我们是如何处理的。

每日站会

每日站会（Stand-up ）：是每天进行的会议旨在在组队成员之间进行状态更新。'半实时'的状态允许参与者了解到潜在的挑战以及用于处理一个困难或者耗时的问题的协调精力。它在一些敏捷软件开发过程中有着特定的价值，譬如Scrum，但是同样可以在任何开发方法论中被使用。术语 “站” 衍生于通过保持与会人员站立的状态（长时间站立会导致不适）从而帮助控制会议的时间的实践。

我们每天会早上花十几分钟（具体时长看团队大小），大家一起站（是站）在卡墙前过卡。卡墙其实就是 Team中的任务看板。就这样，我们从“已验收”列到“待办中”列，从上往下，一张卡一张卡的过。这里的卡是指定义了一个小功能需求的卡片。

站会不过是向领导汇报

我在实践每日站会的时候，发现不少人把每日站会当成一种“向领导汇报”的过程。比如他们会习惯地汇报：我昨天做了1，2，3 blabla。一大串，仿佛说得少就是做的少。所以这个过程，我不断地指正，你们不是在向领导汇报，我们只需要对这件事情负责，说到你的卡时，你就说你的卡的当前状态就好了。慢慢地团队里就养成了对事不对人的文化。为什么呢？每日站会就是提醒我们每日的工作就是对这些“事”负责。

随着时间迁移，我们的团队就慢慢习惯了这种站会。也会在站会上开一些开玩笑了。不要认为这是浪费时间，这是团队文化中很重要的一部分。

站会时间把控问题

站会还可能会遇到的问题是站会时间的把控。所以，我们每日站会会有一个主持人。如果大家说偏题了，主持人就必须指正，让相关人在站会后自己讨论。如果大家讨论的这个问题是个大问题，那么，也是在站完会后再讨论。另外，主持人还要是轮换的，这样就可以将团队所有成员带入项目。

站会上的新人问题

每日站会常常遇到的问题是过卡时，这个人说得太细了，把功能的具体实现细节都说出来了。这时，我们不应该立即打断他。出现这样的情况，说明他一定是新人。我们应该选择在站会后单独找他重申一次每日站会的目的和内容。当然，一开始实践每日站会时，团队里除了你每个人都不懂时，你就有必要马上指正了。

代码审查

代码审查（Code review）是指对计算机源代码系统化地审查，常用软件同行评审的方式进行，其目的是在找出及修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。代码审查常以不同的形式进行，例如结对编程、非正式的看过整个代码，或是正式的软件检查。

我今天没有什么好说的

一开始，我实践时，遇到的最大问题是：团队成员喜欢说，我今天没有什么好说的。这句话听起来冷漠，其实背后的原因是大家不完全理解代码审查是什么，而不是因为他们真的没什么好说的。

这时，我会说：只要你今天做了的事情，你都可以说。然后，他们常常不知从何说起，接着，一上来就给我们讲代码细节。

遇到这种情况，我们需要再强调一遍代码审查需要说什么：上下文、你是如何解决问题的、解决过程遇到什么问题……有时被审查的人可能说的不够明白，我就会帮助补充。

这个过程，你可能会发现有些人在表达能力上的不足，导致听的人一头雾水。我的做法是理解他说的，然后尝试帮助他更好表达出来。这样，提升他的表达能力的同时，让他在团队里也更有归属感。

说得太多了

有时，有些成员可能会说的非常非常细。多人这样了，就会导致代码审查的时间过长。发生这种情况，将表达能力的问题排除外，大概就是这个人没考虑哪些应该是自己应该重点说出来的。这时leader就要站出来指正了。

没写代码怎么审查？

其实，我们实践的代码审查并不是十分严格。因为有时，我们一天下来没有写代码，而是做调研工作。遇到这种情况，被审查人也需要主动分享他今天的习得。有时，他说出来某个问题，也许其他成员也遇到过同样的问题，并解决了。这样就为团队节约时间。

结对编程

结对编程（Pair programming）是一种敏捷软件开发的方法，两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。两个程序员经常互换角色。

如何将结对编程带入团队？

我们的做法由一个懂得结对的人分别和团队里每一个人进行结对。结对前，详细说明结对可能遇到的情况，比如双方有争执，一直都是一个人写的情况，双方都遇到不懂的情况……然后，结对时穿插结对编程的知识。

团队成员中的两个都没有结对编程的经验，怎么办？

实际情况是我们遇到更麻烦的事情。

因为我在前端不擅长，所以我决定让两名前端结对。问题来了，这两个人都不会结对，在沟通方面也不是非常擅长。让他们结对后，我发现他们一起结对的时间非常少，一天下来基本就是各做各的。这时，我发现不对劲。我就分别找他们谈。为什么要分别呢？是希望他们大胆说自己的感受。

在和他们谈了之后，发现根本原因是他们没有完全理解结对编程的目的。这时，找到他们俩再重申一遍结对编程是为了什么，以及如何结对。

新人对结对编程常常有的疑惑？

他在写代码，我看着有什么用？

软件开发是一项集体脑力活，知识的流动在这项活动中非常关键。结对编程是促进知识流动的行为。

看别人写代码的人，我们称为“观察者”。写代码的人，我们称为“驾驶员”。观察者的职责是对写代码的人的代码进行审查。其实除了这点，我更看重的是这个分享思维方式的过程，会加速双方的成长。这个过程还能营造一种相互学习的文化。

我觉得我一个人一下子就写完了

说这句话的人的能力不会差。其实有这样的想法很正常。这时，我们就鼓励他多分享。当我深究下去时，他说写那些东西根本不需要动脑。还很得意的样子。不知道你们有没有发现其中的问题：他在做体力活。更大的问题是：他还不知道自己在做体力活。这时，我会说：当你在做体力活时，和机器没有区别，说明你在退步，这时，你应该跳出来，挑战自己，比如coach别人，或找到一种避免这种体力活的方法。

如果你有什么疑惑，可在本文评论留言。

以下是小结

每日站会，代码审查，结对编程实践的先后顺序的？

本质上是没有先后顺序的。但是如果你是一位新来的leader，你就需要考虑你加入的团队的情况了。我们是先施行每日站会，代码审查。最近一个月才开始实施结对编程。为什么呢？因为对这些编程实践，如果强硬推行，可能会受到排斥。你需要时间让团队成员消化。

给人留下“什么都管”的印象

由于我带来了这些新的实践，看到团队成员实践过程的一些问题就会指出，所以经常给人“什么都管”的印象。

当leader什么都管时，leader要问自己为什么什么要管，而团队成员也要反问自己为什么什么都要被管。排除leader的性格问题外，大多数时，是因为团队还处于比较初级的阶段。你问问自己，团队里有多少人可以自己做leader的就知道了。leader应该跟大家说清楚这点。这样大家就理解你了。但是这个“初级”的阶段要多长时间？就要看你什么时候培养出另一个leader了。

你会发现我在本文没有谈什么M捷或者精Y，是因为我想就事论事，不想谈理论，只想解决实际问题。

问题来了，你发现团队中没有人会结对，你作为leader不懂得如何结对编程时，怎么将结对编程带入团队中呢？

这时就需要请外援了。好听一些，请咨询顾问。如果你觉得看了我的文章，觉得我还行，也可以找我。我在开源中国众包发布了一个专家服务：将每日站会、代码审查、结对编程带入团队

当然，你觉得看这文章对你有帮助，也可以打赏10元：

雪球在股市风暴下的高可用架构改造分享

Mon, 17 Aug 2015 09:20:43 CST

本文根据唐福林老师在“高可用架构”微信群所做的《股市风暴下的雪球架构改造经验分享》整理而成，转发请注明来自微信公众号ArchNotes。

唐福林，雪球首席架构师，负责雪球业务快速增长应对及服务性能与稳定架构优化工作。毕业于北京师范大学，之前曾任微博平台资深架构师，微博技术委员会成员。长期关注并从事互联网服务后端性能及稳定性架构优化工作。

分享主题

一. 雪球公司介绍

二. 雪球当前总体架构

三. 雪球架构优化历程

四. 聊聊关于架构优化的一些总结和感想

一. 雪球公司介绍

雪球聪明的投资者都在这里。

web 1.0：新闻资讯，股价信息，K线图
web 2.0：SNS 订阅，分享，聊天
web 3.0：移动 APP，交易闭环

雪球现在员工数还不到100，其中技术人员占一半。去年9月C轮融资4kw刀。我们现在的技术栈由下列组件组成：Java，Scala，Akka，Finagle，Nodejs，Docker ，Hadoop。我们当前是租用IDC机房自建私有云，正在往“公私混合云”方向发展。

在雪球上，用户可以获取沪深港美2w+股票的新闻信息，股价变化情况，也可以获取债券，期货，基金，比特币，信托，理财，私募等等理财产品的各类信息，也可以关注雪球用户建立的百万组合，订阅它们的实时调仓信息，还可以关注雪球大V。雪球当前有百万日活跃用户，每天有4亿的API调用。App Store 财务免费榜第 18 名。历史上曾排到财务第二，总免费榜第 19。

二. 雪球当前总体架构

作为一个典型的移动互联网创业公司，雪球的总体架构也是非常典型的设计：

最上层是三个端：web端，android端和iOS端。流量比例大约为 2：4：4 。web3.0 的交易功能，在 web 端并不提供。
接入层以及下面的几个层，都在我们的自建机房内部。雪球当前只部署了一个机房，还属于单机房时代。正在进行“私有云+公有云混合部署”方案推进过程中。
我们当前使用 nodejs 作为 web 端模板引擎。nodejs 模块与android 和 ios 的 app 模块一起属于大前端团队负责。
再往下是位于 nginx 后面的 api 模块。跟 linkedin 的 leo 和微博的 v4 一样，雪球也有一个遗留的大一统系统，名字就叫 snowball 。最初，所有的逻辑都在 snowball 中实现的。后来慢慢的拆出去了很多 rpc 服务，再后来慢慢的拆出去了一些 http api 做成了独立业务，但即便如此，snowball 仍然是雪球系统中最大的一个部署单元。
在需要性能的地方，我们使用 netty 搭建了一些独立的接口，比如 quoto server，是用来提供开盘期间每秒一次的股价查询服务，单机 qps 5w+，这个一会再细说；而 IM 服务，起初设计里是用来提供聊天服务，而现在，它最大的用途是提供一个可靠的 push 通道，提供 5w/s 的消息下发容量，这个也一会再细说。
雪球的服务化拆分及治理采用 twitter 开源的 finagle rpc 框架，并在上面进行了一些二次开发和定制。定制的功能主要集中在 access log 增强，和 fail fast，fail over 策略及降级开关等。 finagle 的实现比较复杂，debug 和二次开发的门槛较高，团队内部对此也进行了一些讨论。
雪球的业务比较复杂，在服务层中，大致可以分为几类：第一类是web1.0，2.0 及基础服务，我们称为社区，包括用户，帖子，新闻，股价，搜索等等，类比对象就是新浪财经门户+微博；第二类是组合及推荐，主要提供股票投资策略的展示和建议，类比对象是美国的motif；第三类是通道，类似股市中的“支付宝”，接入多家券商，提供瞬间开户，一键下单等等各种方便操作的功能。
雪球的业务实现中，包含很多异步计算逻辑，比如搜索建索引，比如股票涨跌停发通知，比如组合收益计算等等，为此，我们设计了一个独立的 Thread/Task 模块，方便管理所有的后台计算任务。但随着这些 task 越来越多，逻辑差异越来越大，一个统一的模块并不是总是最佳的方案，所以，我们又把它拆成了两大类：流式的，和批量式的。
雪球的推荐体系包括组合推荐“买什么”和个性化推荐。我们最近正在重新梳理我们的大数据体系，这个感兴趣的话可以单聊。
最下面是基础设施层。雪球基础设施层包括：redis，mysql，mq，zk，hdfs，以及容器 docker。
线上服务之外，我们的开发及后台设施也很典型：gitlab开发，jenkins打包，zabbix 监控系统向 openfalcon 迁移，redimine向confluence迁移，jira，以及内部开发的 skiing 后台管理系统。

三. 雪球架构优化历程

首先描述一下标题中的“股市动荡”定语修饰词吧：

上证指数从年初的3000点半年时间涨到了5000多，6月12号达到最高点5200点，然后就急转直下，最大单日跌幅 8.48%，一路跌回4000点以下。最近一周都在3900多徘徊。

3月最后一周，A股开户 166万户，超过历史最高纪录 2007年5月第二周165万户。

4月份，证监会宣布A股支持单用户开设多账户。

6月底，证金公司代表国家队入场救市。

7月份，证监会宣布严打场外配资。

7月27号将近2000股跌停，IM推送消息数超过平时峰值300倍

外网带宽消耗，一年10倍的增长

中国好声音广告第一晚，带来超过平时峰值200倍的注册量

挑战：小 VS 大：

小：小公司的体量，团队小，机器规模小
大：堪比大公司的业务线数量，业务复杂度，瞬间峰值冲击

雪球的业务线 = 1个新浪财经 + 1 个微博 + 1 个 motif + 1 个大智慧/同花顺。由于基数小，API调用瞬间峰值大约为平时峰值的 30+ 倍。

挑战：快速增长，移动互联网 + 金融，风口，A股大盘剧烈波动。

首先，在app端，在我们核心业务从 web2.0 sns 向 3.0 移动交易闭环进化的过程中，我们开发了一个自己的 hybrid 框架：本地原生框架，加离线 h5 页面，以此来支撑我们的快速业务迭代。当前，雪球前端可以做到 2 周一个版本，且同时并行推进 3 个版本：一个在 app store 等待审核上线，一个在内测或公测，一个在开发。我们的前端架构师孟祥宇在今年的 wot 上有一个关于这方面的详细分享，有兴趣的可以稍后再深入了解。

雪球App实践—构建灵活、可靠的Hybrid框架 http://wot.51cto.com/2015mobile/ http://down.51cto.com/data/2080769

另外，为了保障服务的可用性，我们做了一系列的“端到端服务质量监控”。感兴趣的可以搜索我今年4月份在环信SM meetup上做的分享《移动时代端到端的稳定性保障》。其中在 app 端，我们采用了一种代价最小的数据传输方案：对用户的网络流量，电池等额外消耗几乎为0

每个请求里带上前一个请求的结果

succ or fail ： 1 char
失败原因：0 – 1 char
请求接口编号： 1 char
请求耗时：2 – 3 char
其它：网络制式，etc

炒股的人大多都会盯盘：即在开盘期间，开着一个web页面或者app，实时的看股价的上下跳动。说到“实时”，美股港股当前都是流式的数据推送，但国内的A股，基本上都是每隔一段时间给出一份系统中所有股票现价的一个快照。这个时间间隔，理论上是3秒，实际上一般都在5秒左右。交了钱签了合同，雪球作为合作方就可以从交易所下属的数据公司那里拿到数据了，然后提供给自己的用户使用。

刚才介绍总体架构图的时候有提到 quote server ，说到这是需要性能的地方。

业务场景是这样的，雪球上个人主页，开盘期间，每秒轮询一次当前用户关注的股票价格变动情况。在内部，所有的组合收益计算，每隔一段时间需要获取一下当前所有股票的实时价格。起初同时在线用户不多，这个接口就是一个部署在 snowball 中的普通接口，股价信息被实时写入 redis ，读取的时候就从 redis 中读。后来，A股大涨，snowball 抗不住了。于是我们就做了一个典型的优化：独立 server + 本地内存存储。开盘期间每次数据更新后，数据接收组件主动去更新 quote server 内存中的数据。后续进一步优化方案是将这个接口以及相关的处理逻辑都迁移到公有云上去。

对于那些不盯盘的人，最实用的功能就是股价提醒了。在雪球上，你除了可以关注用户，还可以关注股票。如果你关注的某只股票涨了或跌了，我们都可以非常及时的通知你。雪球上热门股票拥有超过 50w 粉丝（招商银行，苏宁云商）粉丝可以设置：当这支股票涨幅或跌幅超过 x%（默认7%）时提醒我。曾经连续3天，每天超过1000股跌停，证监会开了一个会，于是接下来2天超过1000股涨停

原来做法：

股票涨（跌）x%，扫一遍粉丝列表，过滤出所有符合条件的粉丝，推送消息

新做法：

预先建立索引，开盘期间载入内存
1%：uid1，uid2
2%：uid3，uid4，uid5
3%：uid6
问题：有时候嫌太及时了：频繁跌停，打开跌停，再跌停，再打开。。。的时候

内部线上记录：

4台机器。
单条消息延时 99% 小于 30秒。
下一步优化目标：99% 小于 10 秒

IM 系统最初的设计目标是为雪球上的用户提供一个聊天的功能:

送达率第一
雪球IM：Netty + 自定义网络协议
Akka ：每个在线client一个actor
推模式：client 在线情况下使用推模式
多端同步：单账号多端可登录，并保持各种状态同步

移动互联网时代，除了微信qq以外的所有IM，都转型成了推送通道，核心指标变成了瞬间峰值性能。原有架构很多地方都不太合适了。

优化：

分配更多资源：推送账号actor池
精简业务逻辑：重复消息只存id，实时提醒内容不推历史设备，不更新非活跃设备的session列表等等
本地缓存：拉黑等无法精简的业务逻辑迁移到本地缓存
优化代码：异步加密存储，去除不合理的 akka 使用

akka这个解释一下：akka 有一个自己的 log adapter，内部使用一个 actor 来处理所有的 log event stream 。当瞬间峰值到来的时候，这个 event stream 一下子就堵了上百万条 log ，导致 gc 颠簸非常严重。最后的解决办法是，绕过 akka 的 log adapter，直接使用 logback 的 appender

线上记录：5w/s （主动限速）的推送持续 3 分钟，p99 性能指标无明显变化

7月10号我们在中国好声音上做了3期广告。在广告播出之前，我们针对广告可能带来的对系统的冲击进行了压力测试，主要是新用户注册模块，当时预估广告播出期间2小时新注册100万

压测发现 DB 成为瓶颈：

昵称检测 cache miss > 40%
昵称禁用词 where like 模糊查询
手机号是否注册 cache miss > 80%
注册新用户：5 insert

优化：

redis store：昵称，手机号
本地存储：昵称禁用词
业务流程优化：DB insert 操作同步改异步

下一步优化计划：

将 sns 系统中所有的上行操作都改成类似的异步模式
接口调用时中只更新缓存，而且主动设置5分钟过期，然后写一个消息到 mq 队列，队列处理程序拿到消息再做其它耗时操作。
为了支持失败重试，需要将主要的资源操作步骤都做成幂等。

前置模块HA：

合作方合规要求：业务单元部署到合作方内网，用户的敏感数据不允许离开进程内存
业务本身要求：业务单元本身为有状态服务，业务单元高可用

解决方案：

使用 Hazelcast In-Memory Data Grid 的 replication map 在多个 jvm 实例之间做数据同步。
java 启动参数加上 -XX:+DisableAttachMechanism -XX:-UsePerfData，禁止 jstack，jmap 等等 jdk 工具连接

关于前置模块，其实还有很多很奇葩的故事，鉴于时间关系，这里就不展开讲了。以后有机会可以当笑话给大家讲。

组合净值计算性能优化：

一支股票可能在超过20万个组合里（南车北车中车，暴风科技）
离线计算，存储计算后的结果
股价3秒变一次，涉及到这支股票的所有组合理论上也需要每 3 秒重新计算一次

大家可能会问，为什么不用户请求时，实时计算呢？这是因为“组合净值”中还包括分红送配，分股，送股，拆股，合股，现金，红利等等，业务太过复杂，开发初期经常需要调整计算逻辑，所以就设计成后台离线计算模式了。当前正在改造，将分红送配逻辑做成离线计算，股价组成的净值实时计算。接口请求是，将实时计算部分和离线计算部分合并成最终结果。

实际上，我们的计算逻辑是比较低效的：循环遍历所有的组合，对每个组合，获取所有的价值数据，然后计算。完成一遍循环后，立即开始下一轮循环。

优化：

分级：活跃用户的活跃组合，其它组合。
批量：拉取当前所有股票的现价到 JVM 内存里，这一轮的所有组合计算都用这一份股价快照。

关于这个话题的更详细内容，感兴趣的可以参考雪球组合业务总监张岩枫在今年的 arch summit 深圳大会上的分享：构建高可用的雪球投资组合系统技术实践 http://sz2015.archsummit.com/speakers/201825

最后，我们还做了一些通用的架构和性能优化，包括jdk升级到8，开发了一个基于 zookeeper 的 config center 和开关降级系统

四. 聊聊关于架构优化的一些总结和感想

在各种场合经常听说的架构优化，一般都是优化某一个具体的业务模块，将性能优化到极致。而在雪球，我们做的架构优化更多的是从问题出发，解决实际问题，解决到可以接受的程度即可。可能大家看起来会觉得很凌乱，而且每个事情单独拎出来好像都不是什么大事。

我们在对一个大服务做架构优化时，一般是往深入的本质进行挖掘；当我们面对一堆架构各异的小服务时，“架构优化”的含义其实是有一些不一样的。大部分时候，我们并不需要（也没有办法）深入到小服务的最底层进行优化，而是去掉或者优化原来明显不合理的地方就可以了。

在快速迭代的创业公司，我们可能不会针对某一个服务做很完善的架构设计和代码实现，当出现各种问题时，也不会去追求极致的优化，而是以解决瓶颈问题为先。

即使我们经历过一回将 snowball 拆分服务化的过程，但当我们重新上一个新的业务时，我们依然选择将它做成一个大一统的服务。只是这一次，我们会提前定义好每个模块的 service 接口，为以后可能的服务化铺好路。

在创业公司里，重写是不能接受的；大的重构，从时间和人力投入上看，一般也是无法承担的。而“裱糊匠”式做法，哪里有性能问题就加机器，加缓存，加数据库，有可用性问题就加重试，加log，出故障就加流程，加测试，这也不是雪球团队工作方式。我们一般都采用最小改动的方式，即，准确定义问题，定位问题根源，找到问题本质，制定最佳方案，以最小的改动代价，将问题解决到可接受的范围内。

我们现在正在所有的地方强推3个数据指标：qps，p99，error rate。每个技术人员对自己负责的服务，一定要有最基本的数据指标意识。数字，是发现问题，定位根源，找到本质的最重要的依赖条件。没有之一。

我们的原则：保持技术栈的一致性和简单性，有节制的尝试新技术，保持所有线上服务依赖的技术可控，简单来说，能 hold 住。

能用cache的地方绝不用db，能异步的地方，绝不同步。俗称的：吃一堑，长一智。

特事特办：业务在发展，需求在变化，实现方式也需要跟着变化。简单的来说：遗留系统的优化，最佳方案就是砍需求，呵呵。

当前，雪球内部正在推行每个模块的方案和代码实现的 review，在 review 过程中，我一般是这样要求的：

技术方案：

20倍设计，10倍实现，3倍部署
扩展性：凡事留一线，以后好相见

技术实现：

DevOps：上线后还是你自己维护的项目，实现的时候记得考虑各种出错的处理
用户投诉的时候需要你去解释，实现的时候注意各种边界和异常
快速实现，不是“随便实现”，万一火了呢：性能，方便扩容

Q&A

Q1：im能详细讲下吗？

关于雪球 im 和推模式，有群友问到了，我就再展开讲一下（其实下周我约了去给一家号称很文艺的公司内部交流IM实现）：雪球自己设计了一套 IM 协议，内部使用 netty 做网络层，akka 模式，即为每一个在线的 client new 一个 actor ，这个 actor 里面保持了这个在线 client 的所有状态和数据。如果有新消息给它，代码里只要把这个消息 tell 给这个 actor 即可。actor 里面会通过 netty 的 tcp 连接推给实际的 client。

Q2：问一个小问题，App的接口可用上报里如果是网络问题引起的故障怎么兼容？

app 如果发起一个请求，因为网络问题失败了（这其实是我们的上报体系设计时，最主要针对的场景），那么 app 会把这个失败的请求记录到本地内存，等下一次发请求时，把上次的这个失败请求结果及相关信息带上。如果连续多次失败，当前我们的做法是，只记录最后一次失败的请求结果，下次成功的请求里会带上它。

Q3：监控系统为何从zabbix切换到openfalcon，原因是什么？

简单来说，机器数上百之后，zabbix就会有很多问题，个人感受最大的问题是，新增 key 非常不方便。小米因为这些问题，自己做一个 falcon，然后开源了。我们碰到的问题很类似，看了看小米的，觉得可以不用自己再折腾了，就用它了。

Q4：前置模块的Hazelcast In-Memory Data Grid 的稳定性怎么样，采用的考虑是什么呢？用sharding redis 怎么样呢？

稳定性不能算很好，只能说还好。因为上线几个月，已经出了一次故障了。采用它，主要是开发简单，因为它就只有一个 jar 包依赖，不像其它备选项，一个比一个大。至于为什么不用 redis，因为这是要部署到别人的内网的啊，更新很麻烦的啊，运维几乎没有的啊，各种悲剧啊。我们当前为了做到“一键更新”，把shell脚本和所有jar包都打成一个自解压的文件这事我会随便说吗？

Q5：雪球im如何判断用户是否在线？要给给定的用户发消息，怎么找到对应的actor？不在线的时候消息如何存储？

IM 用户在线判断（转化成指定的 actor 是否存在）和路由，这些都是 akka 内置提供的，感兴趣的，算了，我个人建议是不要去碰 akka 这货。用户不在线的时候，消息会进 mysql 和 redis

Q6：大师，为了支持失败重试，需要将主要的资源操作步骤都做成幂等。这个怎么理解，具体怎么玩？

举个例子：用户发一个帖子，api调用的时候已经给用户返回成功了，但后端写 db 的时候超时了，怎么办？不能再告诉用户发帖失败了吧？那就重试重试再重试，直到写 db 成功。但万一重试的时候发现，上次写入超时，实际上是已经写成功了呢？那就需要把这个写入做成幂等，支持多次写入同一条记录。简单来说，db 层就是每个表都要有业务逻辑上的唯一性检查

Q7：另外用户对应的Actor需不需要持久化呢？

actor 不持久化。重启 server 的话，app 端会自动重连的

Q8：基于zookeeper的config center设计有什么指导原则或遇到什么坑吗？如何方便业务开发修改又不影响到其他？

我们的 config center 有两个版本：一个是参考 netflix 的 archaius，另一个是纯粹的 zk style 。风格问题，我个人的回答是：大家喜欢就好。 config center 本来就不影响业务开发修改啊？没有太明白问题点，sorry

Q9：刚才的追问下如果只报最后一次故障那么会不会不能准确评估影响？

不会的，因为这种情况一般都是用户进电梯或者进地铁了，呵呵

Q10：rpc是怎么选的呢，比如为什么不用thrift呢？

finagle 底层就是 thrift 啊。就我个人而言，我个人对于任何需要预先定义 proto 的东西都深恶痛绝。所以现在我们也在尝试做一个基于 jsonrpc 的简单版本的 rpc 方案，作为我们后续微服务容器的默认 rpc

Q11：实质上是用actor包住了netty的session吧？不建议用akka的原因是量大了后承载能力的问题吗？雪球im的dau约在50万左右吧？

是的，actor 内部持有网络连接。不建议用 akka 的原因是：我个人的原则是，我 hold 不住的东西就不做推荐。就当前来说，我觉得我 hold 不住 akka：使用太简单太方便，但坑太多，不知道什么时候就踩上了，想用好太难了

Q12：唐老师您好，雪球的架构中，rabbitmq 主要用在哪些场景，rabbit的负载是通过哪些手段来做呢?

当前我们的 mq 功能都是有 rabbitmq 提供的，我们在内部封装了一个叫 event center 的模块，所有的跟 queue 打交道的地方，只需要调用 event center 提供的 api 即可。我们对于 rabbit 并没有做太多的调优，大约也是因为现在消息量不大的缘故。后续我们的大数据体系里，queue 的角色会由 kafka 来承担

Q13：大师，能说说akka为啥不推荐么

看上面问题 12

Q14：唐大师，关于交易这块，能说下你们的账户体系吗？

股票交易跟支付宝模式还是很大不一样的，本质上，雪球上只是一个纯粹的通道：钱和股票都不在雪球内部。所以，我们当前的账户体系就像我们页面上描述的那样：将用户的券商账号跟雪球id做绑定

Q15：性能规划上有什么经验或者推荐资料阅读吗？谢谢。

通读 allthingsdistributed 上的精华文章 http://www.allthingsdistributed.com/

Q16：唐大师，雪球的docker是怎么用？怎么管理的？

参考雪球sre高磊在 dockercn 上的分享

Q17：追加一个问题：对业务合规要求的需求不是很了解，但是“-XX:+DisableAttachMechanism -XX:-UsePerfData”这样无法禁止“jstack -F”的吧，只是禁止了普通的jstack。

应该是可以禁止的，因为 jvm 内部所有挂载机制都没有启动，jstack 加 -f 也挂不上去。要不我一会测一下再给你确认？

Q18：帮我问个问题：这么多系统，如何保证迭代保质保量按时交付？

这就要感谢我们雪球的所有技术，产品，运营同事们了 [Tongue]

Q19：为什么用kafka替换rbt?

因为 rbt 是 erlang 写的啊，我不会调优啊，出了问题我也不会排查啊。事实上，event center 模块极偶发的出现丢消息，但我们一直没有定位到根源。所以，只好换了

Q20：请问百万活跃用户session是怎么存储的？怎么有效防止大面积退出登录？

用户登录 session 就存在 jvm 内部。因为是集群，只要不是集群突然全部挂，就不会出现大面积重新登录的

Q21：每个请求里带上前一个请求的结果,这个得和用户请求绑定上吧？

收集 app 端的访问结果，大部分情况下用于统计服务质量，偶尔也用于用户灵异问题的追逐

Q22：akka的设计居然和Erlang的抢占式调度很像，也存在单进程瓶颈问题？

可以这么说，主要是它的 log actor 是单个的

Q23：集群环境下如何保存在jvm内部？各个jvm如何共享的？

我们的 im 系统其实分 2 层，前面有一层接入层，后面是集群。接入层到集群的链接是按 uid 一致性 hash。简单来说，一个用户就只连一个 jvm 服务节点。所以我们只在收盘后更新服务。在雪球，盘中严禁更新服务的

Q24：接入层的实现架构方便描述一下吗？

雪球IM的接入层分为2类：app接入层和web接入层。app接入层是一个 netty 的 server，开在 443 端口，但没有使用 ssl ，而是自己用 rsa 对消息体加密。netty 收到消息后，解包，根据包里的描述字段选择发往后端的业务节点。web 接入层是一个基于 play 的 webserver，实现了 http 和 websocket 接口，供 web 使用

（完）

雪球App是一款解决股票买什么好问题的手机炒股应用。因为独特的产品设计和运营策略，雪球App在市场上拥有领先的份额和影响力。雪球正在招聘，热招职位请参考 http://xueqiu.com/about/jobs (可点击阅读原文进入) 我们在望京 SOHO 等你！

本文策划庆丰@微博, 内容由王杰编辑，庆丰校对与发布，Tim审校，其他多位志愿者对本文亦有贡献。读者可以通过搜索“ArchNotes”或长按下面图片，关注“高可用架构”公众号，查看更多架构方面内容，获取通往架构师之路的宝贵经验。转载请注明来自“高可用架构（ArchNotes）”公众号

【干货】大众点评运维架构的图文详解

Wed, 25 Nov 2015 10:39:29 CST

分享内容

今天分享专题大纲如图所示，从5个方面跟大家一起探讨：

1、点评运维团队的配置

目前我们运维分为4个组，相信跟大部分公司一样，运维团队分为：应用运维、系统运维、运维开发和监控运维，当然还有DBA团队和安全团队，这里就不一一罗列了。整个运维团队全算上目前是不到40人规模。

我们团队分工是这样的：

应用运维：负责支持线上业务，各自会负责对应的业务线，主要职能是保证线上业务稳定性和同开发共同支撑对应业务，以及线上服务管理和持续优化。
运维开发：帮助运维提升工作效率，开发方便快捷的工具，实现运维平台化自动化。
系统运维：负责操作系统定制和优化，IDC管理和机器交付，以及跳板机和账号信息管理。
监控运维：负责发现故障，并第一时间通知相关人员，及时处理简单故障和启动降级方案等。

2、点评的整体架构

先看下点评的机房情况。

点评目前是双机房结构，A机房主跑线上业务，B机房跑测试环境和大数据处理作业，有hadoop集群、日志备份、灾备降级应用（在建）等。点评目前机房物理机+虚拟机有近万台机器。

点评的整体架构，还是跟多数换联网公司一样，采用多级分层模式，我们继续来详细看下点评整体架构。

上面这幅图基本概括了点评的整体架构环境：

用户引导层用的是第三方的智能DNS+CDN。
负载均衡首先是F5做的4层负载均衡之后是dengine做的7层负载均衡（Dengine是在tengine基础上做了二次开发）。再往后是varnish做的页面缓存之后请求到web端 web端通过内部协议调用service（RPC）。
图片存储用的是mogileFS分布式存储。
所有业务，全部有高可用方案，应用全部是至少2台以上。
当然，具体业务要复杂很多，这里只是抽象出简单层面，方便各位同学理解。

目前，点评运维监控是从4个维度来做的：

业务层面，如团购业务每秒访问数，团购券每秒验券数，每分钟支付、创建订单等（cat）。
应用层面，每个应用的错误数，调用过程，访问的平均耗时，最大耗时，95线等（cat）。
系统资源层面：如cpu、内存、swap、磁盘、load、主进程存活等（zabbix）。
网络层面：如丢包、ping存活、流量、tcp连接数等（zabbix cat）。

3、点评运维系统介绍

点评的运维和平台架构组做了很多实用的工具，这些工具组成了点评的整体运维体系。

目前自动化运维比较热，但自动化运维个人觉得是一种指导思想，没必要硬造概念和生搬硬套。自动化在很多公司百花齐放，各家有各家的玩法。但不管怎么定义，运维人员都必须从不同纬度去面对和解决企业所存在的问题。

点评在这方面，也是摸着石头过河，我们的思路是先造零件，再整合，通过零件的打造和之间的整合，慢慢勾勒出一条适合自己的运维自动化框架。

我们运维的理念是：

能用程序干活的，坚决程序化、平台化；
能用管理解决的问题，不用技术解决；
同一个错误不能犯三次；
每次故障，都是学习和提升的机会；
每个人都要有产品化思维，做平台产品让开发走自助路线；
小的，单一的功能，组合起来完成复杂的操作（任务分解）；

所以，我们将自己的理念，融入到自己的作品中，做出了很多工具。

首先整体做个说明，点评运维工具系统汇总：

全方位监控系统：覆盖业务、应用、网络、系统等方面，做到任何问题，都可直观反馈。对不同应用等级，做到不同监控策略和报警策略。
自动化工具系统：对重复的、容易出错的、繁琐的工作尽可能工具化，通过小的策略组合，完成大的任务。
配置和管理系统：对于复杂的配置管理，尽可能web化、标准化、简单化，有模板定义，有规范遵循。
记录和分析系统：对发生的问题和数据做记录并分析，不断的总结、完善和提升。

下面就跟大家来一一介绍下：

3.1 全方位监控系统

Zabbix大家应该非常熟悉了，这里就不做介绍，主要介绍下cat监控。

业务监控：

这张是cat的应用监控图表，可直观从业务角度看出问题，可跟基线的对比，发现问题所在。如图所示，此时支付远偏离基线，流量正常，可能后端出了问题。

除了这些，还有创建订单、支付、首页访问、手机访问等业务数据。

这张图是从业务角度来监控的。

这张也是从业务层面来监控的，该图展示的是手机的访问量趋势图，下面包括延迟、成功率、链接类型、运营商等都有明确数据，该监控可全方位覆盖业务。

应用监控：

从业务层面往下，就是应用层面。

应用状态大盘可清晰表示当前业务组件状态，如果某个业务不可用，其下面某个应用大量报错，说明可能是该应用导致。

该监控大盘十分清晰明的能展示业务下面的应用状态，可在某业务或者某域名打不开的时候，第一时间找出源头。

下图为应用报错大盘，出问题的应用会实时登榜（每秒都会刷新数据），当出现大故障时，运维人员可一眼看出问题；而当多个不同业务同时报错时，则可能是公共基础服务出了问题。

再看下图的这个功能，是Cat最强大的功能，能完整显示应用之间调用过程，做了什么事情，请求了那些，用了多长时间，成功率是多少，访问量是多大，尽收眼底。 Cat几乎无死角的覆盖到业务和应用层面的监控，当然还可做网络等层面监控，总之非常强大。这也是点评的鹰眼系统。

Logscan日志扫描工具:

Logscan系统，是一套日志扫描工具，可根据你定义的策略，对日志内容进行定时扫描，该工具可覆盖到基于日志内容的检测，结合zabbix和cat，实现无死角覆盖。比如有一些攻击的请求，一直遍历你的url，通过cat、zabbix等都无法灵活捕获，有了日志扫描，便可轻松发现。

3.2 自动化工作系统

首先介绍下点评的流程系统-workflow系统

顾名思义workflow是一套流程系统，其核心思想是把线上所有的变更以标准化流程的方式，梳理出来。

我们遵循一个理念，能用程序跑，就不去人操作。

流程有不同状态的转化，分别为发起、审计、执行、验证等环节。用户可自行发起自己的需求变更，通过运维审核，操作（大部分是自动的），验证。如扩容、上线、dump内存、封IP等都为自动化流程。

以我们线上自动化扩容流程为展示，用户使用时，需要填写对应信息，提交后，运维在后台审核过后，就完全自动化扩容，扩容完成会有邮件通知，全程运维不需要登录服务器操作。（自动化倒不是太复杂的技术难题，通过小的任务组合，设置好策略即可）. 几十台机器的扩容，运维只需点个审核通过按钮，数分钟而已。

经过长时间的推广，点评现在98%以上变更都是通过工作流平台完成的，所有变更全部有记录，做到出问题时有法可依，违法可纠。

而且通过流程单的使用频率，可做数据分析，了解哪些操作比较频繁，能否自动化掉，是否还有优化空间。这才是做平台的意义，以用户为导向。

流程系统就介绍到这里，朋友们可关注下其中核心思想。

下面介绍另一套重量级核心系统：Button系统

Button是一套代码管理、打包、部署上线系统，开发可完全自主化进行上传代码，自动化测试，打包，预发，灰度上线，全部上线，问题回滚等操作。全程运维不用干预，完全平台自主化。

点评的运维，除了有些没法自动化的手动配置下，其他基本都是开发自助。这就是自动化的威力！

Go平台系统，是一套运维操作系统，其中包含了很多常规操作、如批量重启、降级、切换、上下线、状态检测等。

该系统主要是解决运维水平参差不齐，工具又各有各的用法，比如说批量重启操作，有用ssh、有用fabric、有自己写shell脚本的。干脆直接统一，进行规范，定义出来操作，通过平台化进行标准化。由于长时间不出问题，偶尔出一下，运维长时间不操作，找个批量重启脚本还要找半天。哪些不能自动化的，我们基本都做到go里了，在这里基本都是一键式的傻瓜操作了。

现在，我们监控团队就可以灵活操作，不需要有多高的技术含量，并且每次操作都有记录，做好审计和授权。

所有后台基本都是python、shell脚本实现，小的脚本组再整合成任务，这也是我们的重要理念之一。对于比较复杂的任务，我们进行分解，然后用小的，单一的功能，组合起来完成复杂的操作（任务分解）。其实我们实现自动化也是这个思路，先造零件，再拼装。

尽管有了puppet，go等工具，但对于一些job作业的管理，也显得非常吃力，我们架构组的同学做出一套任务调度系统。相当于分布式的crontab，并且有强大的管理端。完全自主化管理，只需要定义你需要跑的job，你的策略，就完全不用管了。会自动去做，并且状态汇报、监控、等等全部都有记录，并实现完全自助化。

以上这些系统都非常注重体验，都有非常详细的数据统计和分析，每过一段时间，都有人去看，不断改进和优化，真正做到产品自运营。还有一些自动化系统就不一一介绍了。

3.3 配置和管理系统

先介绍下puppet管理系统，相信不少同学对puppet语法格式深恶痛绝，并且也领教过一旦改错造成的故障严重性。

而且随着多人协同工作后，模板和文件命名千奇百怪，无法识别。

针对这些问题，点评就做了一套管理工具，主要是针对puppet语法进行解析，实现web化管理，并进行规范化约束。

跟go系统一样的想法，将puppet中模块进行组合，组合成模块集（方法集），可方便识别和灵活管理。

下面展示的是我们的软负载均衡管理页面，该系统是线上SLB的管理系统。其核心在于把nginx语法通过xml进行解析，实现web化管理，傻瓜式配置，规范化配置，避免误操作，版本控制，故障回滚等。

点评系统很多，基本上遇到个痛点，都会有人想办法把痛点解决。

下面就介绍下点评另一套强大配置系统，lion。

Lion是一套应用配置管理系统，点评的所有应用用到的配置，不在本地文本文件存储，都在一个单独系统存储，存储以key/value的方式存储。并且也是完全平台化，运维负责做好权限控制和审计。开发全部自助。

其核心是用了zookeeper的管理机制，将配置信息保存在 Zookeeper 的某个目录节点中，然后将所有需要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台应用机器就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中。

是不是在点评做运维轻松很多？各种操作都工具化，自助化，自动化了。那运维还需要做什么。

3.4 记录和分析系统

此类系统虽然不怎么起眼，但对我们帮助也是特别大的，我们通过一些系统的数据记录和分析，发现了不少问题，也解决不少潜在问题，更重要的是，在这个不断完善总结的过程中，学习到了很多东西。

这个是我们故障分析系统，所有的故障都会做记录，故障结束后都会case by case的进行深入分析和总结。其实以上很多系统，都是从这些记录中总结出来的。

该系统为故障记录系统，每个故障都有发生的缘由和改进的方案，定期有人review。

运维起来很轻松吗？也不轻松，只是工作重点有了转移，避开了那些重复繁琐的工作，和开发同学深度结合，共同注重运营质量和持续优化。

再来看下图所示是点评的DOM系统，即运营质量管理平台，该平台汇总了线上的服务器状态、应用响应质量、资源利用率、业务故障等全方位的数据汇总平台。

并通过同比和环比，以及平均指标等数据，让各开发团队进行平台化PK，性能差的运维会去推动改进。

最后一个需要介绍的是雷达系统，该系统是我们最近在做的，一个比较高大上的项目。

朋友们也感受到了，我们系统之多，出问题查起来也比较费时。不少同学生产环节也遇到过类似问题，出了问题到底是什么鬼？到底哪一块引起的呢？结合这个问题，我们把线上的问题做了个分类，并给了一些策略层面的算法，能快速显示。可让故障有个上下文的联系，如：上线时间、请求数下降、错误数增多等，哪个先出现，哪个后出现？当然，这块功能还在做，目标是实现出问题的时候，一眼就能从雷达系统定位问题类型和范围。

以上向大家演示的就是点评的运维系统，相信我们点评的运维思想都在里面体现了。

运维点评这几年的发展，主要目标是实现平台规范化、运维高效化、开发自主化。

之前也是通过运维root登录，然后写脚本批量跑命令的低效运维。也经历过CMDB系统信息不准确，上线信息错乱的尴尬局面。也遇到过出了很大问题，运维忙来忙去，找不到rootcase。

好在，通过努力，这些问题现在都有了很大改观，相信朋友们通过展示的系统，能感觉出点评运维的进步。

4、运维踩过的坑和改进的地方

我就这些年，点评运维出的一些case案例，跟大家聊一聊我们做了哪些具体工作:

变更不知道谁做的，无法恢复，变更完也找不到根据，造成重大故障。//之前线上puppet通过vim的管理方式，由于运维同学失误推了一个错误配置，导致全部业务不可用1个小时，我们后面通过规范puppet配置修改并做成工具，进行权限控制，还加了流程系统，进行避免。
出了问题，开发说代码没问题，运维说环境没问题，该找谁？//我们后面做了工具，通过DOM和cat系统，可进行深度诊断，基本很容易定位问题所属。
执行了个错误命令，全线都变更了，导致服务不可用。//我们通过go系统，进行日常操作梳理，并做成工具，运维90%操作都可通过自动化流程和go平台完成。大大缩减故障产生率，并且之后进行权限回收。
出问题了，各种系统翻来查去，无法快速定位，找不到rootcase。//点评正在做雷达系统，就是将历史存在的问题，进行复盘，将一些故障类型，进行分级，然后通过策略和算法，在雷达系统上进行扫描，出问题环节可快速第一时间优先显示。
运维天天忙成狗，还不出成绩，天天被开发吐槽。//点评这两年完全扭转了局势，现在是运维吊打开发，因为我们目前，大部分系统都实现了开发自助化，运维被解放出来，开始不断完善平台和关注业务运营质量，我们dom系统是可定制的，运维每天都把各业务的核心指标报表发到各位老大那里，哪些服务质量差，响应慢，开发都会立即去改。（当然，需要老大们支持）。

5、未来关注的领域和方向

点评也有些前沿的关注点，比如比较热的Paas技术。

PaaS和云很热，还有docker技术，点评也不能掉队，目前点评有数千个docker的实例在跑线上的业务。

上图java都是跑的docker实例

目前点评Docker这块可做到10秒内快速部署业务并可响应用户请求。30秒内可完成一次实例无缝迁移。个人感觉docker技术不在于底层这块，在于上层管理系统的构造。底层一方面是持续优化，挖掘性能，但更重要的是在策略层和调度层。如何快速部署、迁移、恢复、降级、扩容等，做好这些还有不少挑战。

点评这两年成长很多，但需要走的路也很多，未来关注的点会在多系统的有机整合和新技术的尝试以及发展，还会更多的关注智能策略层面。

结束语

在最后结束时，感谢各位到场朋友捧场，也感谢点评运维和平台架构的每一位同事，有了你们，点评运维才走到了今天，我们共同努力，来创造新时代的运维体系。

点评很多系统都是第一次拿出跟大家分享，大家可看一下设计理念和思想。

创业未必给职业生涯加分

Mon, 11 Apr 2016 16:25:26 CST

最近面试了很多技术人员，其中不少之前的工作履历还不错。但是，因为他们之前的创业经历，我并不能发offer。

看到这里先别着急下结论，让我仔细说说理由。

这样的人员的经历比较类似：在大公司做过五六年，有了比较充分的工作经验和工作习惯，具有一定的管理能力——然后出去创业，过了不到一年，开始找工作。

刚开始我很好奇，为什么刚创业一年就找工作呢？答案几乎前篇一律：营销不行、产品不行。辛辛苦苦做了大半年，技术上的问题都解决了，可就是找不到用户。找不到用户就没有收入，没有收入就难以证明商业模式。加上如今风投行情渐冷，拿投资的难度高了很多，不得已，只能出来找工作，希望做回原来的角色。

于是我问起专业技术的问题，然后只能遗憾的发现，创业的经历对这些候选人来说并不能加分。虽然身处创业公司，他们的角色和之前大公司并没有太多差别：定技术架构、管技术团队、盯开发进度。对他们来说，这些任务已经像条件反射一样轻车熟路。于是，下面的问题也很难答上来：

基于你们公司的具体情况，在选型和技术架构上有什么需要特别考虑的吗？
你们在具体工作中有没有遇到之前没遇到的技术问题，这种问题是创业公司的通病吗？人家是怎么解决的？
你觉得产品不好，营销不好，那么你觉得从产品和营销上可以做哪些改进？你和产品、营销的负责人谈过吗？

如果问这些问题得不到满意的回答，多半可以判断这段创业经历对候选人来说没什么特别，本质上是平移之前的工作经验和解决方案，虽说换了环境，做的还是同样的事情。既没有深入思考不同场景下的技术方案，也没有了解行业的情况，更没有展现出创业公司需要的所有者意识。这段经历给他们留下深刻印象的是：资源太少，工作太累，什么事都要自己做。

更加不幸的是，即便对专业技术，这段创业经历也没有太多的加分。做开发的还是做开发，充其量对不熟悉的领域有了一些了解，却因为忙碌而不够深入。而且因为行政管理上花了不少时间精力，对基础技术已经不再敏锐，与新技术、新思维也拉开不小的距离。

最终的局面就相当尴尬：创业经历对他们来说，技术上没有什么提升，业务上也没有什么提升，只是多了一些行政管理的经验而已。然而一旦离开创业公司，他们期望拿到更高的薪水，相当多的人有“我有创业经历”或者“补偿创业期间低薪损失”的想法；结果甚至无法保持自己创业之前的薪酬水平，因为这样的技能组合并不是非初创公司迫切需要的。对这样的职业生涯经历，我们只能称其为“失败”。

所以我通常还会问最后一个问题：“你当时为什么决定去创业呢？” 因为我想知道，是什么诱使这些候选人做出了职业生涯的重大牺牲。可惜的是，答案五花八门：想勇敢尝试的，想帮同学和熟人忙的，之前领导叫自己一起的，其他人给画了一张大饼…… 只有极少数人能回答“我想清楚了，我就想做这件事情”，这种答案是要加分的。

从公司的角度出发，我们很难和这样的候选人谈得拢；从行业同仁的角度出发，我想郑重告诉大家创业的风险很高，创业本身成功率就很低，更可能耽误自己的职业生涯发展，赔了夫人又折兵。根据我的经验，这里有几点建议给大家参考。

创业是风险极高的投入。

媒体上渲染的成功者有几十几百，你看不到的失败者就有几万几十万。而且，那几十几百成功者的素质，未必强过失败的几万几十万。运气这回事，成功者不愿意承认，媒体不愿意总结，但又是任何创业者都必须面对的。所以在你决定投身创业之前，一定要做好直面运气、承认运气的准备。

投入创业最好以自己认同创业目标为前提。

除非你已经有了相当的资本或者积累，否则“帮朋友忙”这类理由根本不足以支撑做出创业的决定。因为在创业过程中，身处绝境、走投无路乃是常事。如果没有对最终目标的坚定信念，半途而废是常见的结局。

创业是对人品和人性的严峻考验。

不要以为这只是“能共患难不能同享福”那么简单，更不要天真地以为靠制度就可以保障自己“同享福”的权益。而且退一步说，很多时候大家还没到享福的阶段，就已经因为计较彼此对患难的承担“不公平”而分崩离析了。这种计较未必只源于他人，自己身处煎熬之中会是怎么表现，只有亲身经历了才知道，谁也不能预知。稍好一点的情况是，虽然度过了最艰苦的时期，大家没有撕破脸皮，内心却留下了抹不去的阴影，长期来看这种心理状况并不健康，自己生活也不会快乐。当然，如果你自己极度认同创业目标，或许能避免这种风险。

即便在创业公司也不应当忽略自己的职业生涯建设，避免出现“两头不沾”的悲剧。

与上面提到的那些候选人不同，我见过一些经历过创业失败的人，他们或者掌握了跨领域和部门沟通协调、全面解决问题的经验，或者具备了从整个行业观察和思考的能力——总之，创业经历对他们来说是大大加分的，由专变能，具备了解决复杂任务的能力，这种机会在规范公司并不常见。结果即便创业不成功，他们再出去找工作，也可以得到比之前更好的职位和待遇。相反，如果忽略职业生涯建设，在创业公司事情做了不少，却只积累了一堆不相干的打杂经历，拿不出更有力的职业技能组合，又没有收到应有的回报，这是最大的悲剧。

身为普通技术人员，如果不具备产品、管理、营销等经验，在投身创业之前应当仔细读读与创业有关的书籍。

即便它们不能保证你怎样能成功，起码能让你知道怎样做不会成功。“辛辛苦苦把产品做出来，却根本找不到用户”这样的悲剧，已经发生过很多次了，我们作为后人应当尽量早地发现，尽量早地避免。

当然，我不是希望给大家的创业激情泼冷水，我只希望大家在投身创业之前能仔细思考。尤其是在各项社会保障不健全，行业又高速发展的情况下，创业的风险可能被放大若干倍，作用到自己身上。所以，如果你只是“为创业而创业”的话，一定要谨记：创业不等于职业生涯加成。

长期通过微博、微信、知乎等平台接收碎片化的知识有什么弊端？

Mon, 20 Jul 2015 02:42:31 CST

“碎片化”是移动互联网时代的大势，虽说一方面可以将这样的趋势理解做“合理运用时间”。然而长期接受碎片信息的后果也是有弊端的，即碎片化的信息极其容易被我们遗忘。你以为你得到了很多，但其实你什么都没有得到。希望今天分享的文章对同样碎片化的你们有些用。

分享人：张颖

作者：Lachel (知乎)

你所接受的一切信息，构成了你的思维方式。

所以，长期接受碎片信息的后果，就是让你的思维变得狭隘，难以进行复杂的思考。

1、碎片信息通常具备这样的特征：

它们往往是一些事实的集合而非逻辑
它们往往大量简化了推演过程
它们往往将多路径简化为单一路径
它们往往不够严谨、全面……

简而言之，碎片信息为了达到易于习得的目的，通常会显著降低认知成本，最明显的方式就是：将复杂的事物简单化。它们往往只告诉你表面上的东西，却不会告诉你背后的原理，以及它与其他事物之间的联系。

我们所说的「知识」，由两部分组成：一是「事实」（或曰「观念」），二是「联系」。事实就是一个个点，联系则是把点连接起来的线，它们所构成的网络，就是我们的知识结构。

「事实」决定了你的知识广度，「联系」决定了你的知识深度。如果你了解事物之间的联系，即使你只知道ABC，你也可以根据这三者的内在逻辑，得出DE，甚至F，这个过程就叫做思考。但如果你不了解它们的内在逻辑，即使你知道ABCDE，你也是没办法得出F的——你不知道需要把它们放在一起，更不知道放在一起之后它们能够呈现出怎样的内在逻辑关系。

这就是碎片化信息的弊端。当我们接受碎片信息时，我们实际上是在扩充「事实」，但并没有增加「联系」。 长此以往，会使我们的知识结构变成一张浮点图：孤零零的知识点漂浮在各个位置，却缺乏一个将它们有序串联起来的网络。

2、这样的结果是：

1.碎片化知识通过连续的新鲜内容，不断刺激你的大脑，让你始终处于「啊！又知道了新的东西」的喜悦中，从而难以自拔，这也就是我们难以抑制刷微博、刷朋友圈的缘故，因为我们只需要付出很少，就可以沉浸在「获得了新东西」的刺激里面。

但是，这些获得的信息，因为它们 缺少跟其他信息的「联系」，因此难以被我们「提取」，而「提取」得越少的内容，会被提取得多的内容挤压在记忆的底部——因此，这些碎片化的信息极其容易被我们遗忘。你以为你得到了很多，但其实你什么都没有得到。

2.前文已经说过，我们的知识网络，决定了我们如何思考。那么，长期接受碎片信息，对你的思考能力并没有提升——你的「网络」并没有扩大；甚至是有害的——你已经习惯了用孤立的知识点去看待问题，习惯了一层、两层的思维，难以对事物进行五层、六层乃至更深入的剖析。 长此以往，你将弱化对于复杂事物的思考能力。

这里要注意一点：碎片化信息，其实跟来源没有太大关系。如果你习惯了接受「A是B」、「C是坏的」、「因为A所以B」的简单观念，那么，无论你是在刷微博，还是在读书、看公开课，其实接受的都是碎片化知识。

我之前在一个「聪明人的思考方式是什么」的问题中，提到过：聪明人的思考方式，其实很简单，就是三个字：元认知。同样一个问题，较为聪明的人，会去思考这个问题产生的背景、原因、合理性、必要性、可能性，等等。他们会 拔高一层去看待这个问题，从而更容易找到一根线条，将它和远处的某个固有的「观念」联系在一起，从而拓展自己的思维网络。

所以，如果你有这样的意识，那么其实无论刷微博还是读书，都可以避免碎片化认知。

3、具体的方式是：

1.先花一点时间，建立自己的知识体系。

把你已经知道的东西梳理一遍。如何梳理呢？以你能够说出某个知识点的影响因素，以及它对其他事物的影响为准。顺着这样的知识点捋一遍，这个网络就是你已经构建完成的知识网络。

2.找到知识网络的触点。亦即自己感兴趣的、但尚未进行探索和了解的知识点。阅读、学习的时候，有意识地去接触这些触点的知识，延展自己的知识网络。

3.当接触到一个新的知识点时，先考虑如何将其纳入知识体系。

亦即在脑子里回想你的知识网络，思考它可以如何跟你已经知道的东西联系起来。

4.如果找到了对应的点，弄通路径。

亦即，将这个新的知识点，跟已经知道的某个点之间的路径，查清楚、弄清楚，将它们连接起来，使这个知识点成为你新的「触点」，拓展你的思维网络。

5.检验并输出。

将这两个点之间的联系讲清楚。最简单的办法，就是通过口述、写文章，去教会别人这个知识。或者，在心里把它讲一遍，看是否能够讲得清晰易懂，没有障碍。只有能够输出的东西，才是真正属于你的东西。

6.不符合以上方式的内容，果断舍弃。

如果一个东西无法纳入你的认知体系，那说明你现在还不能掌握它，那就果断放弃，因为它对你来说是没有价值的，或者说（记忆的）成本是远高于收益的。

4、再多谈几点

1.读书不用追求「读完一本书」，而应该追求「从这本书中获得了什么东西」。

一本书的内容不可能100%对你有用，其中肯定有你所不感兴趣的东西，也有你所无法接受的东西，没关系，接受你所能接受的即可。不用务求全部读完。甚至，读一半，放回去，再跳着读别的书，也是很好的方式。读书应该为自己所用，而不是让自己去迁就它。

2.如何处理微博上、知乎上那些有趣的碎片化知识？

个人建议，最好的方式，是将它们作为起点。如果你觉得一个知识很有趣，就 以它为出发点，去探索它背后的原理、背景、应用，去查资料、GOOGLE，顺藤摸瓜。这个知识点本身是没有太大价值的，有价值的是你去探索的过程。你经过探索了解到的东西，才能纳入你的知识体系，成为你思维的一部分。

3.以上种种都需要不菲的时间，但学习本就是一件艰难的事情，所以优秀的人永远是凤毛麟角，所谓 聪明的人，无非他们把走路、等车、休息等更多的时间花在这上面罢了。再说，学习本身，岂非也是一件很有趣的事情？:)

点击“Refer链接”还可浏览作者的另外一篇文章：怎么样才能让学习体系化，效果更好？ - Lachel 的回答。希望对你有用。

5、Refer：

[1] 长期通过微博、微信、知乎等平台接收碎片化的知识有什么弊端？

http://www.zhihu.com/question/30489442/answer/51507979

[2] 网络把我们变傻了吗？

http://user.qzone.qq.com/463148357/blog/1422463146

[3] 怎么样才能让学习体系化，效果更好？

http://zhi.hu/apJx

[4] 如何构建自己的笔记系统？

http://zhi.hu/5xsA

在互联网时代如何工作得更简单

Mon, 29 Jun 2015 13:07:56 CST

互联网发展这么多年，让人感到可怕的增长之外，信息量已经让每个现代人觉得繁重，我们每天都要处理大量的信息，而且信息的来源都是不一样的，更会让人觉得身心疲惫。在工作中也是一样，每天处理大量的信息会很容易分心，很容易把事情变得复杂。

在这么多信息的干扰下，把工作变得简单会显得非常需要，这决定了你能否充分利用工作时间，给自己更多可用的时间，而不是每天都在应付工作。可以尝试用一些习惯和工具来改善这些问题。

1、特定时间处理特定信息

这个适用于一些处理固定信息的场景，比如：筛选简历、Review 工作进度、审批进度、分配任务、审查代码。比如说：

每天早上上班第一个半小时是定制一天的计划
每天中午下班最后半小时前用来分配新的工作任务
每天下午下班最后一个小时用来审核代码和 Review 工作进度
每天晚上拿一个小时用来筛选简历

这种工作安排是一种比较容易确定的，非常容易提升效率。但比较难的就在于控制外界条件对自己的干扰，和如果打乱如何去安排。

我曾经一段时间要练习翻译，就花了一个多月每天晚上 10 点到 11 点去翻译一些很好的英文文章放到简书，刚开始坚持是很难的，经常会被一些事情打断。慢慢的说服自己去坚持，明白自己坚持背后是为了什么，打打鸡血咬咬牙就过去了；然后把自己封闭到一个环境内，不要去想任何其它的，收个新闻，看个手机都不要去想，专心花一个小时去搞定。这是一个考验耐心的环节。

2、把信息聚合到一起

现在我们每天接触信息非常分散，来自于各种不同的地方，我会用各种各样的工具去解决信息太分散的问题，我的解决手段主要就是聚合。比如：

常见的新闻类，肯定会用 RSS 阅读器，比如 Reeder
想收藏的信息都通过一个 Pocket 来收藏
每个项目要使用的文件都用 Dropbox 这样的服务放到一个文件夹
任务管理尽量不要使用多个平台，如果必须，建立通过 API 聚合到一起

这样其实已经可以把信息的处理尽量放在一起，而不用到处去找，或者切换各种应用或网页去获取信息。已经可以解决很多信息分散的问题。

3、和团队共享信息

团队协作是非常重要的，协作就离不开信息共享，信息不能流通起来就很难把信息同步给大家，造成团队合作不畅。可以尝试使用这些方式：

用 Trello 或 Tower 这样的工具来管理好任务和文件等
用 Gmail 或者 Outlook 等日历来共享日程信息
用 Quip 、 Google Docs 或石墨来共享文档
用 Slack 或我们的产品瀑布IM 来共享信息流，甚至可以来接入以上所有的服务

把信息共享解决后，基本的工作环节都会打通，也会减少很多不必要的沟通。多出来的时间可以和团队做些更有意义的沟通，让整个团队氛围变得生动和开放。工作才会变得简单，问题更容易解决。

写在最后

让工作变得简单有很多方式，但最终离不开的就是对信息的获取和处理。我们现在全部都再用瀑布IM 来进行办公，邮件基本抛开，也不用经常去找信息，因为信息自然会流进来。再加上自己开发的一些 API 接口，可以解决信息流中 80% 的需求，整个工作会变得非常简单。

为什么有些人用一年时间获得了你十年的工作经验？

Tue, 14 Jul 2015 21:45:00 CST

如何用一年的时间获得十年的经验和能力？这篇文章提到了两个神奇的名词——学习曲线与Hacking大脑，就这两个神奇的名词竟然能让一个人用一年的时间收获另一个十年的工作经验？为什么会这么说，大家看了相信就能理解。

文/郝培强Tinyfool

我一直喜欢跟优秀的人来往，和非常优秀的人工作，因为我是一个非常懒惰的人，而我知道跟非常优秀的人工作的时候心情可以非常愉快。

优秀人才的特征：极强的学习能力必不可少

那我自己创业的时候呢，我招的第一个员工，他毕业于漳州一个大学，在那个不是很发达的地方，但他自己学会了怎么做iOS开发，并把自己的软件在AppStore上线。后来我看这个软件做的还不错，他的学历非常烂，也没有什么背景，我都不理解他是怎么学会这些东西的。然后我们开始给他喂一些材料，给他一点点做一些项目，我发现这样的人也是没有什么极限的，于是我给他们做的东西越来越难。后来我发现，原来这个公司我终于不用再做主要程序员了，我终于找到了一个编程水平和我差不多的人，我不干活的人生目标的终于达到了。所以我这些年呢，我一直在想怎么样把人变得优秀。我想要和优秀的人合作。

就有人在问：这样的人你怎么找得到呢？

前两个月呢，我验证了这么一个流程：我让所有人远程工作起来。于是我就在论坛里发了一篇帖子，说我认为远程工作是这个世界的未来，我在想我们下个项目要不要找两个远程工作的人。

当天晚上我就收到了六篇简历，但是其中五个人都不是我想要的人。我就和最后一个人聊，因为最后一个人是做Java后端的。但是呢这个小伙子很无聊的在他的博客中写了有35篇一步步如何应用Java的系列。这的确不是什么特别难的事情，但是我没有见过一个人可以把这样的副项目（side project）做的这么干净、整洁，每一步都写的非常清楚。

所以我就和他说我觉得他是我们想要的人，他问我们的项目要做什么。我告诉他我们要做一个把iOS直接编译成安卓的项目，我让他看了一个我关于这个项目的视频。过了五分钟，他回邮件说，他觉得很难，搞不定。我说我相信你可以搞定，我给你两个星期的时间去学什么叫做iOS开发，你不需要学到非常难，你只需要学到可以做一个最简单的iOS app就表明你会做iOS开发了，你就进我公司了。

两个星期以后，他做了一个app并写了一篇文章来解释这个是怎么回事。看完这篇文章之后，我和我们的CPO说这个人就交给你管了。我特别喜欢这样的人，所以我在想这样的人到底是什么样的人。

去年我过的不是很顺，我就在想我怎么样可以让自己过得积极快乐。我发现这就是一个过程，这个过程就是我能不能够征服一些我征服不了的过程，比如我能不能走一段路把我这身肉减下来。一开始走一两万步，累得吐血。后来我陪一个小朋友去逛外滩，我回家发现我走了三万步，但是我一点事情也没有，这是我去年想象不到的事情。所以我开始写一本很鸡汤的书。

我对这个世界的理解是，这个世界太容易活下来了,可是对于很多人来说不是这样,问题出在哪里呢，在于这个世界变化得太快。在iPhone出来之前我觉得手机应该是一台电脑，但我不知道应该是一台怎么样的电脑。iPhone出来之后我觉得这就是，我相信那个时候没有人会相信iPhone可以把诺基亚搞死但它做到了。但我相信这只是伟大产品的很小的一部分，iPhone把日本的DC和DV搞死了，这才是伟大产品的真正的意义。

大家打过Uber吗？我觉得Uber其实就是我们以前想象的未来智能世界的样子，随时随地都能够打到车。从一个程序员的角度讲，我们应该在出租车的计价器上装一台电脑。但实际上怎么解决的呢，实际上每位司机都有一台手机，这手机并没有强悍到车上去，但这台手机连接到了每一个人。这个世界正在不停地变化。

什么东西都有可能，做一个高级程序员很难吗？同样的一个黑人，可能在美国街头打架，也可能是奥巴马。你想想一个美国街头小混混变成奥巴马有多难，他需要跨越的阶梯更多。

每一个你见到的比你更优秀的人，他到底是有什么天赋异禀呢？

我不太相信这件事情。我见了太多优秀的人，我不认为他们天生的智商比别人高，但是我觉得他们的学习方法、对待事情的认真态度是不可阻挡的。我不知道高博之前在大学挂了11门，我在大学也挂了11门。我是我们大学了唯一一个家长被叫到学校的大学生。

我在校门口接我爸妈时，我爸妈当时觉得特别丢人。但是走着走着，遇见两个人对我说“郝老师好”，我爸妈当时觉得特别惊讶。这两个人参加了我当时在另外一个系做的关于Word、Excel、Powerpoint的演讲。当时我就在想：这个世界其实有不同的评价标准。也许我的大学觉得我应该被开除掉，但是我看到的不完全是一份简历，我觉得每个人具有完全可变的能力，但我们被我们的理解所塑形，把我们变成了一个完全不可变的人。我们会听到别人说“学一门语言好难啊”。五年前有人跟我说“Tiny，该怎么学iOS”，我说“很简单”；五年之后还跟我说“Tiny，该怎么学iOS”，我都无语了。

十年的工作经验or只是一年的工作经验用了十年？

有这么一个笑话，一个人跑去问老板“我都有十年工作经验了，问什么您还不给我涨薪水呢？”，老板回答说 “你是有十年工作经验呢，还是把一年工作经验用了十年呢？”。我觉得在这个社会中有太多人是把一年的工作经验用了十年。刚才也有演讲者提到了《异类》，《异类》的理论是只有当你刻意去学习，当你不停从自己的安全区跳出来，忍受一种痛苦和煎熬，改变了自己以后，你付出的时间才是算数的。

当时我们在珠海讨论学习的问题，其中有一个人说他在进公司前两个星期的时候非常痛苦，觉得他什么都不会，谁都比他强。但后来他可以轻松处理这些事情，他却觉得有些担心了。我问他担心什么，他说他觉得这一年没有什么成长。我觉得他把我点醒了，我给的建议有两个：一是找一份更有挑战性的工作，二是做一个副项目去挑战自己。

“学习曲线”学会终生学习

所以我们在讲，什么叫做学习曲线——横轴是时间，纵轴是能力。我相信我们在校的学习和工作的第一年一定会学到很多东西，但是我见到的很多人工作一年、十年、二十年是完全一样的。那我认为终生学习的人的学习曲线应该是没有尽头的。

有人在论坛上问，现在硅谷都在宣扬二三十岁创业、成功、成为明星的例子，有没有人能够给我举一个四五十岁成功的例子。那么就有个人回复：“我在42岁创办了Craiglist。”Craiglist是分类网站的鼻祖。我当时就懵了，我才36岁，我的人生才刚开始啊。

在任何环境中我们都可以观察，我认为在任何一个不断变化的环境中，终身学习者只能占1%。我的结论是，由于你是一个终身学习者，你可以秒杀在任何一个领域里你的同侪。终身学习者是没有极限的.

学习曲线？正确的学习方法，学做乐学者

我的另一个观察分析是学习的方法有很多种。一般的学习方法是阶段性的，就是学一会儿，休息一会儿，再学一会儿。我们传统教育和我们推崇的人，他们通常是意志力非常坚强人。

比如说我们要考试了，在一个星期之内从完全不懂到能够考试，那么我们的学习曲线将会非常陡峭。我觉得这是一个非常错误的示范。

大多数认为自己不聪明的人来自于用一种错误的方法去学习。我经常遇到一些非常神奇的初学者，有人说“这本iOS这本书看了三天还没有看完”，我想问的是这本是是三天能学会的吗？比如你去爬珠峰掉下来了，然后你说自己是一个失败者。

其实，为什么要这么爬山呢？我在我的公共微信号tiny4voice里一直强调大家不要急，为什么？因为一着急你就会开始做错误的东西。一开始你以为你是神，可以在一个星期内、三天内学会一个非常难的东西。一旦你做不到，你就会觉得你什么都做不到了。我觉得正是这样的原因让大家以为自己不够厉害。

我觉得有了正确的方法以后，大多数人都可以攻克这个问题。我经常和很多人说，刚进入一个项目的时候，学习曲线要平，可怕的平。

比如像我这么一个人，一次就要走三万步的话，大家可能在急诊室看到我。那我第一次的目标是怎么定的呢？第一次我就背了个包，带了很多的补给，不知疲倦的从早上走到晚上，后来我算了一下我大概走了六七公里。我从来不知道我能走六七公里。那么第二天我想既然第一天我走了七公里，那我今天可不可以走八公里呢？有一次我为了见一个朋友，跨了个江，走了十五六公里，后来我觉得我自己太厉害了，后来就一发不可收拾。

我觉得学习曲线一开始比较平，但是当你对一个东西了解了以后，到后面是一个加速度过程。会学习的人在一开始都是非常慢的，在给自己设定基准，并基于自己正反馈的空间，并且永远不会把自己控制得太狠，让自己一下子崩溃掉。

Hacking大脑

我的另一个思考是Hacking大脑。首先我对机器学习非常有兴趣。我觉得机器学习对我们理解人脑是非常有帮助的。

1、机器学习：模型+数据量

机器学习主要有两个东西，一个是模型，另一个是数据量。当你选对了足够的语料、足够的数据量的时候，这个模型会越来越好。我一直在想我们的大脑是一个什么东西。大脑其实是一个反馈的流程，大脑接受了一定的数据、一定的训练，形成了一定的理论，然后不断地去验证这些理论对不对。一个聪明的人大脑的结构应该非常的清晰。

为了学英语练听力，我开始听一些Podcast，一开始我发现我听的不太懂，但由于是自己领域内的东西后来我都能听得懂；于是我开始听一些经济学的东西，发现十几个字母长的东西我也能够听懂，我到现在不知道那些词怎么写，但是我就是能够听得懂。

现在我验证了大脑是一个无穷力量的机器，那我怎么去训练它呢？我觉得我听力有一定水平了，那我能不能够说英语呢？于是我就去参加上海老外的聚会，从一句话不会说到能够和老外争论宗教的问题。我始终觉得我的词汇量是一个问题，那我又开始读英文书，现在我可以看哲学等比较艰涩的书籍了。那后来我发现我要练口语的一种方法，原来一开始我要培养即使看不懂也能读下去的一种感觉，现在我遇到每一个不会的单词都要查，于是我感觉我的口语又在慢慢进步。

2、think fast and slow：避免远古大脑，唯慢不破

我们有两个大脑，一个大脑深思熟虑、功能非常强大；另一个大脑比较像远古的动物不太懂事，但它非常快，有点像反射。通过这个理论我想明白了我们为什么会产生争执，原因很简单。比方说有个老外说“你们中国人……”，另一边就会想“你怎么了，又想说我们中国人了吗？”，但其实他都不知道是要说中国人好还是坏。

很多时候呢，我们都会陷入到一种情绪中，都在用大脑最快但是最愚蠢的部分。所以我在想，我能不能降低我的反应速度，把每一句话都听完，把每一件事情都想完，再回答，就是先听后说。后来我有个理论叫做“不争论”，这也是我们论坛的宗旨，即使你对上一个人的发言有多大分歧，你都只表达我的观点是什么，而不是说“某某某的想法是错的”。因为一旦说了这么一句话，就会陷入到一种以“说服对方”、“压倒对方”为目的的讨论中。实际上我认为每一个讨论的人都会有一些不对的部分，不可能全对。所以我们都在一种不争论或者深思熟虑的环境下，给予大家充分的表达空间，你总是能够收获一些。

我觉得成长就是我们不断去接受这个世界散在很多人、很多书、很多理论里的信息，信息量慢慢地增长，让我们的大脑不断进化。

再回到大脑进化这个问题。我在有个阶段认为，我们大脑的模型进化我是有感觉的。我觉得我英语听力上升的时候，莫名其妙觉得我的粤语听力和上海话听力也在上升。你的大脑其实就是一个复杂机器，当这个机器越来越好的时候呢，不光是对某一个具体的问题有好处。所以我在追求让大脑更复杂更进化，帮我来解决更复杂的事情。

3、the power of habit：把好变为习惯

最后一个是《习惯的力量》，其实这本书的观点与《思考，快与慢》是相反的。它认为我们的习惯存储与我们大脑比较古老低级的部分，比如反射。《习惯的力量》提出了一个我们怎么把一个回路放到大脑古老部分里去的方法。放过去的好处在于，习惯意味着我们做一些事情就会变得很容易。我觉得这本书可以和《异类》一起看：当任何时候你觉得难受，你的大脑就在进化；当任何时候你觉得轻松，你都在使用你的习惯。

但这两种理论对我们都有非常重要的意义。我在想我可不可以用这个理论改造我的习惯，这个理论的内容是：习惯有三个要素——触发条件、流程和奖励。我拿这个理论去可以改造我的走路行为、学日语的行为，效果都非常好。我现在每天大概都能够学40分钟的日语，我能够看到我的日语水平在提升。

结束语：

大脑Hacking的理论，虽然这个理论不够完美，但是我们可以不断地去验证。我可以试试看心平气和的聊天是不是能够更好地交流；我可以试试习惯的理论能不能够把一个我不想做的事情很容易的做到，而一些不想有的坏习惯能不能够戒除掉。希望有一天我能够写一本关于方法论的书，很多人或许会叫它“鸡汤”，但我觉得只要他能够改变别人、改变我自己，那就是对的，谢谢大家。（来源）

您可能也喜欢：
我做淘宝7年的工作经验总结	什么影响我们的时间专注度？	12个时间管理妙招	我们去工作到底为了什么？	一份好工作的标准是什么？
无觅

技术合伙人的故事

Thu, 26 Mar 2015 11:50:38 CST

很多人说百姓网的技术很牛，其实我不觉得牛在哪里，不过有一件事情我自己一直引以为傲，那就是在我们技术团队中诞生了5个以上的技术合伙人，还有更多的人加入了其他创业公司成为了骨干。记得以前有位资深的管理者跟我说，不要总是和下面的人谈创业，谈了他们出去了怎么办？一开始我还真的犹豫了一下，但是后来我想明白了，首先不是你不说了他就不会去创业，愚民政策是没有用的。其次是有人出去了，他说你这里好，才会有更多的好人来。再说一个十年的公司，怎么可以没有人走出去呢？最重要的是，我们需要的是一个人的心，而不是一个人的手，人需要把公司的事情当作自己的事情来做，这个就叫“创业”。

今天我就来谈谈作为一个技术合伙人，经历的3个故事。

迷你朝歌

一个小时内写出一个分类广告网站？这似乎是一个不可能完成的任务吧。但是只要接受我们的training，你肯定可以在一个小时内写出来，当然你要花1天？2天？3天？还是以上呢？按照我们的测试成绩，如果能够在1天内完成，你必然是技术的绝顶高手，百姓网只有1个人达到这样的素质，一般在2天之内写出来的同学，已经算得上是技术不错的同学了。3天是及格线，如果超过3天了，那么基本上可以被淘汰了。没错，基本上，我们最核心的十几名技术人员，全是这样被train出来的。

说起这个迷你朝歌的来历，还要说到我和ceo的代码pk，没错，我们的ceo是写代码的，而且悲剧的事情是他写得还比我好。我从05年加入百姓网的时候，主要任务是招聘人员，然后项目控制，但是随着各种需求的堆积，代码越来越烂，当时最差的时候，几个人看见一段代码谁都不敢下手。由于我之前的工作经历都是在外包公司的，相信的是按部就班的开发步骤，所以ceo说1小时内开发出来，我是不相信的。然后我们两个pk一下哪个代码更快更好，经过一个多星期的pk，最后我发现他的代码真的比我的要好，这是对我的世界观的颠覆。建硕的那句话叫做：你用的是微软的开发方式，而谁都知道微软在互联网时代的处境，这就是用一种落后的思维来做一个新的东西，怎么能够赢呢？

感想：
技术合伙人的技术很重要，但是他的思路不能老，用软件思路做互联网，或者用互联网思路做移动互联网，最后只能把团队带到沟里面。

一封邮件

有一段时间工作特别忙，天天都是12点以后走的，最主要是忙得还没有成就感，而且还看不到头。我相信任何一个技术人员都会经历这样的过程，当时我记得做了一件傻事，就是我发了一封邮件给ceo，意思就是说，你看工作这么多，这么累，大家都这么苦，这么勤奋，可是我不是很开心，和女朋友的关系也不是很好，身体也不是很好，吧啦吧啦。现在想想都觉得好笑，但是就是这么发了。

接下来ceo又来找我了，把我骂了一顿，说你这个叫naiive，当时我懵了，我想我说的都是事实啊，可是我忘了一件事情，我没有给出解决方案。所谓的正能量和负能量最大的区别就是有没有解决方案。愤怒是无能的表现。现在看来的话，这个问题很简单，工作量太大，首先是产能是否足够？产能分成人数和生产效率，如果人数不够就要招人，如果效率下降就要提升效率，调整团队结构，做team building，或者项目攻关等很多种方式。其次是否有很多不需要做的工作，没有成就感的工作，是不是所有的工作都要做，是不是需要进行协调？技术合伙人之所以是合伙人，和其他团队的沟通协作是重要的部分，甚至可以占到一半以上。

感想：
愤怒是无能的表现，无能是因为有框，打破了框框之后就有解了。明确别人的期待，千万不要活在自己的假设之中，对于技术合伙人来说，不是管理好团队就好了，更重要的角色是业务中的技术视角。

天生要快

2011年在qcon上做了一次关于百姓网速度优化的演讲，反响很热烈。这中间背后最主要的原因是我们确实花了1年多的时间进行了速度上的很多工作，取得的效果也是非常显著的，由于在这个上面尝到了甜头，所以我们就持续做这个事情，甚至做到了一些非常之极端的做法，速度是我们的重要考核指标，以至于我们网站上出了用户发的照片以外，没有一张的图片，连我们的logo都改成了文字，后来从alexa上的监控看，我们的速度比google，baidu都要快，唯一还没有赶上的就是craigslist。

可是后来我们发现就算我们再继续努力，能够优化的空间变小了，同时取得的效果也不那么明显了。试想已经几百毫秒了，用户已经几乎分不清楚差别了，很多的优化都有一个临界点，这个临界点就是触发用户感觉的地方，也就是很多事情只要做到足够好就行了，不一定要做到极致的。还有一个因素是，当年南北互通问题是大家都非常头痛的问题，可是随着互联网基础设施建设的提升，大家的带宽越来越大，这个问题就慢慢不是问题了。倒是现在的移动互联网的h5页面速度可能还是问题。

技术在现在大多数创业公司里面的角色还基本上都是支持的角色，真正能够让技术变成业务推动力的情况是很少的。对于百姓网，我看到的少有的能够以技术称为巨大推动力的，一个就是网速称为瓶颈的时代，但是随着时代的变迁，他也变的不是了。另外一个领域就是antispam领域，这个地方好玩的就是因为你是和人在斗，你的对手永远都在升级，防作弊是一个道高一尺魔高一丈的过程，这个时候技术就会变得很重要了。

今天的bing的技术可能已经和google的差不多了，但是大部分人还是习惯用google。当大家都缺少搜索的时候，google领先了那么几年的技术，那就占据了人的内心的那个位置了，接下来喝google做的一样已经没有机会了，除非你要好10倍，那就是革命性的。

感想：
能够找准并且做出技术上的那个重要引擎是技术合伙人一直考虑的事情。

总结

三个故事讲完了，如果硬要讲一个中心思想的话，那就是要不断地突破自己思维上的框框。如果讲顺序的话，要先把自己的事情做好，然后帮别人一起把事情做好，最后要能够带领大家把事情做好，找技术即业务的那个结合点。

目前腾讯哪个部门最值得加入？为什么？

Sun, 22 Mar 2015 21:06:13 CST

小编题记：文章是从知乎看来的，作者应该是鹅厂的。文章中详细的叙述了作为一个鹅厂员工，远没有大家想的那么光鲜。其苦逼程度可能比创业公司还惨、还心酸。当然收益可能也是普通创业公司的2-3倍，但是这2-3倍是用多少汗水和脑细胞换来的，大家可以自我想象。我觉得此文可能对于一些即将进入社会的新鲜人有莫大的帮助，感谢作者。

在互联网这种节奏下，没有一成不变，别用国企、公务员那种老态龙钟的思路在互联网择业。在腾讯，跟对领导、跟对有战斗力的团队，比进所谓的好部门更重要，来来来，说下原因。

首先，腾讯的架构调整太频繁了，进去的时候，你在A部门，没多久，可能A部门就和B部门合并。甚至做着做着，A部门就没了。或者，做个一两年，你变成另一个事业群的人也不是不可能。

腾讯的特色，半年一小调、一年一大调、三年公司级调整，在腾讯，几乎没有不经历过架构调整的员工，相对来说，TEG的调整最少，IEG的最多。

在腾讯，没有永远的牛逼部门，例如腾讯微博，曾经举全公司之力力推的项目，里面的兄弟无限辉煌，而今整个腾讯微博都没了。类似的产品还有腾讯电商等，所以，一开始牛又如何呢？

在腾讯也没有永远差的部门，例如腾讯视频，去年濒临被随时停掉，今年业绩却翻了2.7倍，跟随一个很差的部门一起征战，成为明星部门，年会的时候风光无限好，这样的过程很爽，从差到强，学到的和感受到的都非常宝贵，因此，一开始差又如何呢？类似的产品还有应用宝，也是去年从差变为五星级项目。

也有过山车团队，腾讯彩票，去年从差变强，业绩翻了无数倍，好像还拿了重大业务突破奖（TX的同学确认下，我记不清了）。可是，上个月ZF的一个xx文，这个团队回到原点，现在整体在打酱油，他们在做打地鼠呢，不信你们打开微信，看看彩票。

用腾讯架构调整的时候老板们说得最多的一句话，就是“拥抱变化”。

第二，腾讯有非常棒的内部人才市场，称之为“活水计划”，内部换岗流动通道堪称国内第一。如果你想内部换岗，可以在OA上查找内部岗位，保密面试，面试通过后，原部门三个月内必须无条件放人。

一般说来，假如你没拿过2星以下的差评考核结果，换岗是很顺利的。如果你拿到了5星优秀考核结果，几乎是岗位等着你啦，你会被各个老板们抢着要。

腾讯有个习惯，招人的时候，用人单位首先都会看看内部人才市场有没有人适合，甚至是直接去相似部门挖人（别奇怪，腾讯内部挖人很正常），招内部的人可以更快适应企业文化，更快上手，甚至带来了其它的附加价值。

也就是说，腾讯内部机会很多，只要你做事“靠谱”，换岗太简单了，几乎腾讯所有部门都有机会去。如果你做事“非常靠谱”，刚好认识的部门也多，你当前部门架构调整的时候，会有很多别的部门的老板给你抛来邀请。鹅们有时候开玩笑说，部门架构调整时，去处的多少是衡量一个企鹅在腾讯做事靠谱程度的非官方指标。

在腾讯做事，开会的时候，经常会遇到这样的场景：啊，企鹅Q，你原来不是在A部门干活的吗？啥时候变成B部门的人了？

好了，我想表达的是，互联网没有一成不变的部门，在做事的过程中学习和感悟到的更重要。例如前文说到的腾讯微博的哥们，在做腾讯微博的时候，随着用户量级的提升，开发兄弟们体会到了用户量剧增带来的技术压力，他们从中得到了锻炼。产品兄弟们体会到了为何会失败，这个失败是腾讯花几十亿给他们交的学费，聪明人从中受的益不会比做一个成功产品少。而今，腾讯微博的TX们，遍布腾讯各个产品线，很多都是各个产品线的核心骨干。

对了，即使是好部门，里面也会分为核心业务线、支撑线，对于需要进腾讯的人来说，很难选，也没法选。

所以，别去挑部门，没意义，产品方向可以换，部门可以做没，这些真不重要，因为在腾讯这些变化都太快了。进去之后你会发现，跟对领导、跟对一个有战斗力的团队更重要，明白人自会明白。

本来来源：知乎

互联网从业者必备微信公众号：woshipm，如果你已经关注了，证明你已经很牛逼了。

MYSQL数据库常用知识整理

Mon, 01 Jun 2015 16:39:03 CST

MYSQL数据库常用知识整理

什么是MYSQL
MYSQL的特性
MYSQL存储引擎的分类以及数据文件的介绍
MYSQL赋权
MYSQL备份与恢复
MYSQL的基本操作:增删查改
MYSQL的基本故障判断与处理
MYSQL的调优
MYSQL主主、主从复制的实现
MYSQL大数据备份和恢复
数据文件的损坏与修复

什么是MYSQL

MySQL是一个开放源码的小型关联式数据库管理系统，开发者为瑞典MySQL AB公司。目前MySQL被广泛地应用在Internet上的中小型网站中。由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，许多中小型网站为了降低网站总体拥有成本而选择了MySQL作为网站数据库。

MYSQL的特性

使用C和C++编写，并使用了多种编译器进行测试，保证源代码的可移植性。
支持AIX、BSDi、FreeBSD、HP-UX、Linux、Mac OS、Novell Netware、NetBSD、OpenBSD、OS/2 Wrap、Solaris、SunOS、Windows等多种操作系统。
为多种编程语言提供了API。这些编程语言包括C、C++、C#、Delphi、Eiffel、Java、Perl、PHP、Python、Ruby和Tcl等。
支持多线程，充分利用CPU资源，支持多用户。
优化的SQL查询算法，有效地提高查询速度。
既能够作为一个单独的应用程序应用在客户端服务器网络环境中，也能够作为一个库而嵌入到其他的软件中。
提供多语言支持，常见的编码如中文的GB 2312、BIG5，日文的Shift_JIS等都可以用作数据表名和数据列名。
提供TCP/IP、ODBC和JDBC等多种数据库连接途径。
提供用于管理、检查、优化数据库操作的管理工具。
可以处理拥有上千万条记录的大型数据库。

MYSQL存储引擎的分类以及数据文件的介绍

一、安装与部署、配置文件的介绍

①安装简介

源码编译安装，请大家自己亲自动手编译安装。

(了解不同版本的区别尤其是5.5和5.6)

②配置文件说明

basedir = path	使用给定目录作为根目录(安装目录)。
character-sets-dir = path	给出存放着字符集的目录。
datadir = path	从给定目录读取数据库文件。
pid-file = filename	为mysqld程序指定一个存放进程ID的文件(仅适用于UNIX/Linux系统); Init-V脚本需要使用这个文件里的进程ID结束mysqld进程。
socket = filename	为MySQL客户程序与服务器之间的本地通信指定一个套接字文件(仅适用于UNIX/Linux系统; 默认设置一般是/var/lib/mysql/mysql.sock文件)。在Windows环境下，如果MySQL客户与服务器是通过命名管道进行通信的，–sock选项给出的将是该命名管道的名字(默认设置是MySQL)。
lower_case_table_name = 1/0	新目录和数据表的名字是否只允许使用小写字母; 这个选项在Windows环境下的默认设置是1(只允许使用小写字母)。

mysqld程序：语言设置

character-sets-server = name	新数据库或数据表的默认字符集。为了与MySQL的早期版本保持兼容，这个字符集也可以用–default-character-set选项给出; 但这个选项已经显得有点过时了。
collation-server = name	新数据库或数据表的默认排序方式。
lanuage = name	用指定的语言显示出错信息。

mysqld程序：通信、网络、信息安全

enable-named-pipes	允许Windows 2000/XP环境下的客户和服务器使用命名管道(named pipe)进行通信。这个命名管道的默认名字是MySQL，但可以用–socket选项来改变。
local-infile [=0]	允许/禁止使用LOAD DATA LOCAL语句来处理本地文件。
myisam-recover [=opt1, opt2, ...]	在启动时自动修复所有受损的MyISAM数据表。这个选项的可取值有4种:DEFAULT、BACKUP、QUICK和FORCE; 它们与myisamchk程序的同名选项作用相同。
old-passwords	使用MySQL 3.23和4.0版本中的老算法来加密mysql数据库里的密码(默认使用MySQL 4.1版本开始引入的新加密算法)。
port = n	为MySQL程序指定一个TCP/IP通信端口(通常是3306端口)。
safe-user-create	只有在mysql.user数据库表上拥有INSERT权限的用户才能使用GRANT命令; 这是一种双保险机制(此用户还必须具备GRANT权限才能执行GRANT命令)。
shared-memory	允许使用内存(shared memory)进行通信(仅适用于Windows)。
shared-memory-base-name = name	给共享内存块起一个名字(默认的名字是MySQL)。
skip-grant-tables	不使用mysql数据库里的信息来进行访问控制(警告:这将允许用户任何用户去修改任何数据库)。
skip-host-cache	不使用高速缓存区来存放主机名和IP地址的对应关系。
skip-name-resovle	不把IP地址解析为主机名; 与访问控制(mysql.user数据表)有关的检查全部通过IP地址行进。
skip-networking	只允许通过一个套接字文件(Unix/Linux系统)或通过命名管道(Windows系统)进行本地连接，不允许ICP/IP连接; 这提高了安全性，但阻断了来自网络的外部连接和所有的Java客户程序(Java客户即使在本地连接里也使用TCP/IP)。
user = name	mysqld程序在启动后将在给定UNIX/Linux账户下执行; mysqld必须从root账户启动才能在启动后切换到另一个账户下执行; mysqld_safe脚本将默认使用–user=mysql选项来启动mysqld程序。

mysqld程序：内存管理、优化、查询缓存区

bulk_insert_buffer_size = n	为一次插入多条新记录的INSERT命令分配的缓存区长度(默认设置是8M)。
key_buffer_size = n	用来存放索引区块的RMA值(默认设置是8M)。
join_buffer_size = n	在参加JOIN操作的数据列没有索引时为JOIN操作分配的缓存区长度(默认设置是128K)。
max_heap_table_size = n	HEAP数据表的最大长度(默认设置是16M); 超过这个长度的HEAP数据表将被存入一个临时文件而不是驻留在内存里。
max_connections = n	MySQL服务器同时处理的数据库连接的最大数量(默认设置是100)。
query_cache_limit = n	允许临时存放在查询缓存区里的查询结果的最大长度(默认设置是1M)。
query_cache_size = n	查询缓存区的最大长度(默认设置是0，不开辟查询缓存区)。
query_cache_type = 0/1/2	查询缓存区的工作模式:0, 禁用查询缓存区; 1，启用查询缓存区(默认设置); 2，”按需分配”模式，只响应SELECT SQL_CACHE命令。
read_buffer_size = n	为从数据表顺序读取数据的读操作保留的缓存区的长度(默认设置是128KB); 这个选项的设置值在必要时可以用SQL命令SET SESSION read_buffer_size = n命令加以改变。
read_rnd_buffer_size = n	类似于read_buffer_size选项，但针对的是按某种特定顺序(比如使用了ORDER BY子句的查询)输出的查询结果(默认设置是256K)。
sore_buffer = n	为排序操作分配的缓存区的长度(默认设置是2M); 如果这个缓存区太小，则必须创建一个临时文件来进行排序。
table_cache = n	同时打开的数据表的数量(默认设置是64)。
tmp_table_size = n	临时HEAP数据表的最大长度(默认设置是32M); 超过这个长度的临时数据表将被转换为MyISAM数据表并存入一个临时文件。

mysqld程序：日志

log [= file]	把所有的连接以及所有的SQL命令记入日志(通用查询日志); 如果没有给出file参数，MySQL将在数据库目录里创建一个hostname.log文件作为这种日志文件(hostname是服务器的主机名)。
log-slow-queries [= file]	把执行用时超过long_query_time变量值的查询命令记入日志(慢查询日志); 如果没有给出file参数，MySQL将在数据库目录里创建一个hostname-slow.log文件作为这种日志文件(hostname是服务器主机名)。
long_query_time = n	慢查询的执行用时上限(默认设置是10s)。
long_queries_not_using_indexs	把慢查询以及执行时没有使用索引的查询命令全都记入日志(其余同–log-slow-queries选项)。
log-bin [= filename]	把对数据进行修改的所有SQL命令(也就是INSERT、UPDATE和DELETE命令)以二进制格式记入日志(二进制变更日志，binary update log)。这种日志的文件名是filename.n或默认的hostname.n，其中n是一个6位数字的整数(日志文件按顺序编号)。
log-bin-index = filename	二进制日志功能的索引文件名。在默认情况下，这个索引文件与二进制日志文件的名字相同，但后缀名是.index而不是.nnnnnn。
max_binlog_size = n	二进制日志文件的最大长度(默认设置是1GB)。在前一个二进制日志文件里的信息量超过这个最大长度之前，MySQL服务器会自动提供一个新的二进制日志文件接续上。
binlog-do-db = dbname	只把给定数据库里的变化情况记入二进制日志文件，其他数据库里的变化情况不记载。如果需要记载多个数据库里的变化情况，就必须在配置文件使用多个本选项来设置，每个数据库一行。
binlog-ignore-db = dbname	不把给定数据库里的变化情况记入二进制日志文件。
sync_binlog = n	每经过n次日志写操作就把日志文件写入硬盘一次(对日志信息进行一次同步)。n=1是最安全的做法，但效率最低。默认设置是n=0，意思是由操作系统来负责二进制日志文件的同步工作。
log-update [= file]	记载出错情况的日志文件名(出错日志)。这种日志功能无法禁用。如果没有给出file参数，MySQL会使用hostname.err作为种日志文件的名字。

mysqld程序：镜像(主控镜像服务器)

server-id = n	给服务器分配一个独一无二的ID编号; n的取值范围是1~2的32次方启用二进制日志功能。
log-bin = name	启用二进制日志功能。这种日志的文件名是filename.n或默认的hostname.n，其中的n是一个6位数字的整数(日志文件顺序编号)。
binlog-do/ignore-db = dbname	只把给定数据库里的变化情况记入二进制日志文件/不把给定的数据库里的变化记入二进制日志文件。

mysqld程序：镜像(从属镜像服务器)

server-id = n	给服务器分配一个唯一的ID编号
log-slave-updates	启用从属服务器上的日志功能，使这台计算机可以用来构成一个镜像链(A->B->C)。
master-host = hostname	主控服务器的主机名或IP地址。如果从属服务器上存在mater.info文件(镜像关系定义文件)，它将忽略此选项。
master-user = replicusername	从属服务器用来连接主控服务器的用户名。如果从属服务器上存在mater.info文件，它将忽略此选项。
master-password = passwd	从属服务器用来连接主控服务器的密码。如果从属服务器上存在mater.info文件，它将忽略此选项。
master-port = n	从属服务器用来连接主控服务器的TCP/IP端口(默认设置是3306端口)。
master-connect-retry = n	如果与主控服务器的连接没有成功，则等待n秒(s)后再进行管理方式(默认设置是60s)。如果从属服务器存在mater.info文件，它将忽略此选项。
master-ssl-xxx = xxx	对主、从服务器之间的SSL通信进行配置。
read-only = 0/1	0: 允许从属服务器独立地执行SQL命令(默认设置); 1: 从属服务器只能执行来自主控服务器的SQL命令。
read-log-purge = 0/1	1: 把处理完的SQL命令立刻从中继日志文件里删除(默认设置); 0: 不把处理完的SQL命令立刻从中继日志文件里删除。
replicate-do-table = dbname.tablename	与–replicate-do-table选项的含义和用法相同，但数据库和数据库表名字里允许出现通配符”%” (例如: test%.%–对名字以”test”开头的所有数据库里的所以数据库表进行镜像处理)。
replicate-do-db = name	只对这个数据库进行镜像处理。
replicate-ignore-table = dbname.tablename	不对这个数据表进行镜像处理。
replicate-wild-ignore-table = dbn.tablen	不对这些数据表进行镜像处理。
replicate-ignore-db = dbname	不对这个数据库进行镜像处理。
replicate-rewrite-db = db1name > db2name	把主控数据库上的db1name数据库镜像处理为从属服务器上的db2name数据库。
report-host = hostname	从属服务器的主机名; 这项信息只与SHOW SLAVE HOSTS命令有关–主控服务器可以用这条命令生成一份从属服务器的名单。
slave-compressed-protocol = 1	主、从服务器使用压缩格式进行通信–如果它们都支持这么做的话。
slave-skip-errors = n1, n2, …或all	即使发生出错代码为n1、n2等的错误，镜像处理工作也继续进行(即不管发生什么错误，镜像处理工作也继续进行)。如果配置得当，从属服务器不应该在执行 SQL命令时发生错误(在主控服务器上执行出错的SQL命令不会被发送到从属服务器上做镜像处理); 如果不使用slave-skip-errors选项，从属服务器上的镜像工作就可能因为发生错误而中断，中断后需要有人工参与才能继续进行。

mysqld–InnoDB：基本设置、表空间文件

skip-innodb	不加载InnoDB数据表驱动程序–如果用不着InnoDB数据表，可以用这个选项节省一些内存。
innodb-file-per-table	为每一个新数据表创建一个表空间文件而不是把数据表都集中保存在中央表空间里(后者是默认设置)。该选项始见于MySQL 4.1。
innodb-open-file = n	InnoDB数据表驱动程序最多可以同时打开的文件数(默认设置是300)。如果使用了innodb-file-per-table选项并且需要同时打开很多数据表的话，这个数字很可能需要加大。
innodb_data_home_dir = p	InnoDB主目录，所有与InnoDB数据表有关的目录或文件路径都相对于这个路径。在默认的情况下，这个主目录就是MySQL的数据目录。
innodb_data_file_path = ts	用来容纳InnoDB为数据表的表空间: 可能涉及一个以上的文件; 每一个表空间文件的最大长度都必须以字节(B)、兆字节(MB)或千兆字节(GB)为单位给出; 表空间文件的名字必须以分号隔开; 最后一个表空间文件还可以带一个autoextend属性和一个最大长度(max:n)。例如，ibdata1:1G; ibdata2:1G:autoextend:max:2G的意思是: 表空间文件ibdata1的最大长度是1GB，ibdata2的最大长度也是1G，但允许它扩充到2GB。除文件名外，还可以用硬盘分区的设置名来定义表空间，此时必须给表空间的最大初始长度值加上newraw关键字做后缀，给表空间的最大扩充长度值加上raw关键字做后缀(例如/dev/hdb1: 20Gnewraw或/dev/hdb1:20Graw); MySQL 4.0及更高版本的默认设置是ibdata1:10M:autoextend。
innodb_autoextend_increment = n	带有autoextend属性的表空间文件每次加大多少兆字节(默认设置是8MB)。这个属性不涉及具体的数据表文件，那些文件的增大速度相对是比较小的。
innodb_lock_wait_timeout = n	如果某个事务在等待n秒(s)后还没有获得所需要的资源，就使用ROLLBACK命令放弃这个事务。这项设置对于发现和处理未能被InnoDB数据表驱动程序识别出来的死锁条件有着重要的意义。这个选项的默认设置是50s。
innodb_fast_shutdown 0/1	是否以最快的速度关闭InnoDB，默认设置是1，意思是不把缓存在INSERT缓存区的数据写入数据表，那些数据将在MySQL服务器下次启动时再写入 (这么做没有什么风险，因为INSERT缓存区是表空间的一个组成部分，数据不会丢失)。把这个选项设置为0反面危险，因为在计算机关闭时，InnoDB 驱动程序很可能没有足够的时间完成它的数据同步工作，操作系统也许会在它完成数据同步工作之前强行结束InnoDB，而这会导致数据不完整。

mysqld程序：InnoDB–日志

innodb_log_group_home_dir = p	用来存放InnoDB日志文件的目录路径(如ib_logfile0、ib_logfile1等)。在默认的情况下，InnoDB驱动程序将使用 MySQL数据目录作为自己保存日志文件的位置。
innodb_log_files_in_group = n	使用多少个日志文件(默认设置是2)。InnoDB数据表驱动程序将以轮转方式依次填写这些文件; 当所有的日志文件都写满以后，之后的日志信息将写入第一个日志文件的最大长度(默认设置是5MB)。这个长度必须以MB(兆字节)或GB(千兆字节)为单位进行设置。
innodb_flush_log_at_trx_commit = 0/1/2	这个选项决定着什么时候把日志信息写入日志文件以及什么时候把这些文件物理地写(术语称为”同步”)到硬盘上。设置值0的意思是每隔一秒写一次日志并进行同步，这可以减少硬盘写操作次数，但可能造成数据丢失; 设置值1(设置设置)的意思是在每执行完一条COMMIT命令就写一次日志并进行同步，这可以防止数据丢失，但硬盘写操作可能会很频繁; 设置值2是一般折衷的办法，即每执行完一条COMMIT命令写一次日志，每隔一秒进行一次同步。
innodb_flush_method = x	InnoDB日志文件的同步办法(仅适用于UNIX/Linux系统)。这个选项的可取值有两种: fdatasync，用fsync()函数进行同步; O_DSYNC，用O_SYNC()函数进行同步。
innodb_log_archive = 1	启用InnoDB驱动程序的archive(档案)日志功能，把日志信息写入ib_arch_log_n文件。启用这种日志功能在InnoDB与 MySQL一起使用时没有多大意义(启用MySQL服务器的二进制日志功能就足够用了)。

mysqld程序–InnoDB：缓存区的设置和优化

innodb_log_buffer_pool_size = n	为InnoDB数据表及其索引而保留的RAM内存量(默认设置是8MB)。这个参数对速度有着相当大的影响，如果计算机上只运行有 MySQL/InnoDB数据库服务器，就应该把全部内存的80%用于这个用途。
innodb_log_buffer_size = n	事务日志文件写操作缓存区的最大长度(默认设置是1MB)。
innodb_additional_men_pool_size = n	为用于内部管理的各种数据结构分配的缓存区最大长度(默认设置是1MB)。
innodb_file_io_threads = n	I/O操作(硬盘写操作)的最大线程个数(默认设置是4)。
innodb_thread_concurrency = n	InnoDB驱动程序能够同时使用的最大线程个数(默认设置是8)。

mysqld程序：其它选项

bind-address = ipaddr	MySQL服务器的IP地址。如果MySQL服务器所在的计算机有多个IP地址，这个选项将非常重要。
default-storage-engine = type	新数据表的默认数据表类型(默认设置是MyISAM)。这项设置还可以通过–default-table-type选项来设置。
default-timezone = name	为MySQL服务器设置一个地理时区(如果它与本地计算机的地理时区不一样)。
ft_min_word_len = n	全文索引的最小单词长度工。这个选项的默认设置是4，意思是在创建全文索引时不考虑那些由3个或更少的字符构建单词。
Max-allowed-packet = n	客户与服务器之间交换的数据包的最大长度，这个数字至少应该大于客户程序将要处理的最大BLOB块的长度。这个选项的默认设置是1MB。
Sql-mode = model1, mode2, …	MySQL将运行在哪一种SQL模式下。这个选项的作用是让MySQL与其他的数据库系统保持最大程度的兼容。这个选项的可取值包括ansi、db2、 oracle、no_zero_date、pipes_as_concat。

③启动脚本

二、MYSQL存储引擎的分类: MYISAM INNODB

myISAM：这个是默认类型，它是基于传统的ISAM类型，ISAM是Indexed Sequential Access Method (有索引的顺序访问方法) 的缩写，它是存储记录和文件的标准方法。与其他存储引擎比较，MyISAM具有检查和修复表格的大多数工具。 MyISAM表格可以被压缩，而且它们支持全文搜索。它们不是事务安全的，而且也不支持外键。如果事物回滚将造成不完全回滚，不具有原子性。如果执行大量的SELECT，MyISAM是更好的选择。

MyIASM是IASM表的新版本，有如下扩展：

二进制层次的可移植性。
NULL列索引。
对变长行比ISAM表有更少的碎片。
支持大文件。
更好的索引压缩。
更好的键吗统计分布。
更好和更快的auto_increment处理。

InnoDB：这种类型是事务安全的。它与BDB类型具有相同的特性，它们还支持外键。InnoDB表格速度很快，具有比BDB还丰富的特性，因此如果需要一个事务安全的存储引擎，建议使用它。如果你的数据执行大量的INSERT或UPDATE，出于性能方面的考虑，应该使用InnoDB表。对于支持事物的InnoDB类型的表，影响速度的主要原因是AUTOCOMMIT默认设置是打开的，而且程序没有显式调用BEGIN 开始事务，导致每插入一条都自动Commit，严重影响了速度。可以在执行sql前调用begin，多条sql形成一个事物(即使autocommit打开也可以)，将大大提高性能。

具体可以看看下表：

	MyISAM	InnoDB
构成上区别	每个MyISAM在磁盘上存储成三个文件。文件名为表名，扩展名为文件类型。 .frm 文件存储表定义； .MYD(MYData) 数据文件的扩展名； .MYI(MYIndex) 索引文件的扩展名。	基于磁盘的资源是InnoDB表空间数据文件和它的日志文件，InnoDB 表的大小只受限于操作系统文件的大小，一般为 2GB
事务处理方面	MyISAM类型的表强调的是性能，其执行速度比InnoDB类型更快，但是不提供事务支持。	InnoDB提供事务支持事务，外部键等高级数据库功能。
锁	表级锁	行级锁 InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%”
select、insert、update、delete操作	如果执行大量的 SELECT，MyISAM 是更好的选择。	1.如果你的数据执行大量的INSERT或UPDATE，出于性能方面的考虑，应该使用InnoDB表。 2.DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。 3.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。
对于AUTO_INCREMENT类型的字段	必须包含只有该字段的索引	可以和其他字段一起建立联合索引
		InnoDB不支持FULLTEXT类型的索引。
	MyISAM类型的二进制数据文件可以在不同操作系统中迁移

以下是一些细节和具体实现的差别：

InnoDB不支持FULLTEXT类型的索引。
InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count(*)语句包含 where条件时，两种表的操作是一样的。
对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。
DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。
LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。

综上所述，任何一种表都不是万能的，只有恰当的针对业务类型来选择合适的表类型，才能最大的发挥MySQL的性能优势。

二、MYSQL数据文件的介绍

一、MySQL数据库文件介绍

MySQL的每个数据库都对应存放在一个与数据库同名的文件夹中，MySQL数据库文件包括MySQL所建数据库文件和MySQL所用存储引擎创建的数据库文件。

1、MySQL创建并管理的数据库文件：

.frm文件：存储数据表的框架结构，文件名与表名相同，每个表对应一个同名frm文件，与操作系统和存储引擎无关，即不管MySQL运行在何种操作系统上，使用何种存储引擎，都有这个文件。

除了必有的.frm文件，根据MySQL所使用的存储引擎的不同（MySQL常用的两个存储引擎是MyISAM和InnoDB），存储引擎会创建各自不同的数据库文件。

2、MyISAM数据库表文件：

.MYD文件：即MY Data，表数据文件

.MYI文件：即MY Index，索引文件

.log文件：日志文件

3、InnoDB采用表空间（tablespace）来管理数据，存储表数据和索引，

InnoDB数据库文件（即InnoDB文件集，ib-file set）：

ibdata1、ibdata2等：系统表空间文件，存储InnoDB系统信息和用户数据库表数据和索引，所有表共用

.ibd文件：单表表空间文件，每个表使用一个表空间文件（file per table），存放用户数据库表数据和索引

日志文件： ib_logfile1、ib_logfile2

二、MySQL数据库存放位置：

1、MySQL如果使用MyISAM存储引擎，数据库文件类型就包括.frm、.MYD、.MYI，默认存放位置是C:\Documentsand Settings\All Users\Application Data\MySQL\MySQL Server 5.1\data

2、MySQL如果使用InnoDB存储引擎，数据库文件类型就包括.frm、ibdata1、.ibd，存放位置有两个，

.frm文件默认存放位置是C:\Documents and Settings\All Users\ApplicationData\MySQL\MySQL Server 5.1\data，ibdata1、.ibd文件默认存放位置是MySQL安装目录下的data文件夹

三、 MYSQL赋权

#给用户cacti赋予所有库的所有权限
GRANT ALL PRIVILEGES ON *.* TO 'cacti'@'%' IDENTIFIED BY 'cacti' WITH GRANT OPTION;
#重新载入赋权表
FLUSH PRIVILEGES;

#收回权限(不包含赋权权限)
REVOKE ALL PRIVILEGES ON *.* FROM cacti;
REVOKE ALL PRIVILEGES ON cacti.* FROM cacti;
#收回赋权权限
REVOKE GRANT OPTION ON *.* FROM cacti;
#重新载入赋权表
FLUSH PRIVILEGES;

#查看赋权权限

show grants for 'cacti'@'%'

四、MYSQL备份与恢复

一：实验环境介绍：

系统介绍：CentOS6.4_X64

数据库版本：mysql-5.5.33

二：基于Mysqldump命令实现备份恢复

2.1、思路概念

Mysqldump是一个逻辑备份命令；意思就是将数据库中的数据备份成一个文本文件；也可以说是将表的结构和数据存储在文本文件中。

Mysqldump命令的工作原理很简单，它先查出需要备份的表的结构，再在文本文件中生成一个CREATE语句。然后，将表中的所有记录转换为一条INSTERT语句。这些CREATE语句和INSTERT语句都是还原时使用的。还原数据时就可以使用其中的CREATE语句来创建表。使用其中的INSERT语句来还原数据。它可以实现整个服务器备份，也可以实现单个或部分数据库、单个或部分表、表中的某些行、存储过程、存储函数、触发器的备份；并且能自动记录备份时刻的二进制日志文件及相应的位置。对于InnoDB存储引擎来讲支持基于单事务模式实现热备，对于MyISAM则最多支持温备。

2.2、备份策略

Mysqldump全备+二进制日志增备

2.3、过程实现

（1）Mysqldump全备

由于Mysql数据库默认的为MyISAM存储引擎所以只有使用温备（备份同时仅支持读请求）进行，所以我们要为所有数据库添加读锁

1	`[root@stu18 ~]` #mysqldump -uroot -pmypass --lock-all-tables --master-data=2 --events --routines--all-databases > /zhao/database_`date +%F`.sql

解析：--lock-all-tables表示为所有表施加读锁；--master-data=2表示在备份文件中记录当前二进制日志的位置；--events表示备份数据的同时备份时间调度器代码；--routines表示备份数据的同时备份存储过程和存储函数；--all-databases表示备份所有库。

[root@stu18 zhao] # less database_2013-08-13.sql

-- #表示注释项

-- Position to start replication or point- in - time recovery from

--

-- CHANGE MASTER TO MASTER_LOG_FILE= 'mysql-bin.000001' , MASTER_LOG_POS=14203; #这里表示当前处于mysql-bin.000001这个二进制日志中，事件为14203这是通过--master-data=2产生的

--

-- Current Database: `hellodb`

--

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `hellodb` /*!40100 DEFAULT CHARACTER SET utf8 */;

（2）二进制全备

方法一：导出二进制日志文件内容

1	`[root@stu18 data]` # mysqlbinlog mysql-bin.000001 >/zhao/binlog_`date +%F`.sql

方法二：滚动日志复制文件

1 2	`mysql> flush logs;` `#滚动日志` `[root@stu18 data]` `# cp mysql-bin.000001 /zhao/mysql-bin.000001 #复制导出二进制文件`

（3）二进制增备

首先添加数据信息

1 2	`mysql> use hellodb;` `mysql> INSERT INTO students(Name,Age,Gender,ClassID,TeacherID) values (` `'Yang kang'` `,22,` `'M'` `,3,3);`

然后二进制增备

1	`[root@stu18 data]` # mysqlbinlog --start-position=14203 --stop-position=14527 mysql-bin.000001 > /zhao/binlog_`date +%F_%H`.sql

解析：--start-position=14203是上次全备之后的二进制事件位置；--stop-position=14527最近一天的二进制事件位置。

2.4、模拟数据库损坏，实现恢复工作

mysql> DROP DATABASE hellodb; #删除数据库

############下面这些过程要在离线状态下执行############

mysql> SET sql_log_bin=0; #先关闭二进制日志

mysql> flush logs; #滚动日志

[root@stu18 ~] # mysql -uroot -pmypass < /zhao/database_2013-08-13.sql #导入数据库备份文件

[root@stu18 ~] # mysql -uroot -pmypass < /zhao/binlog_2013-08-13_19.sql #导入增量备份文件

[root@stu18 ~] # mysql -uroot –pmypass #登录查看，恢复完成

mysql> SET sql_log_bin=1; #开启二进制日志

这种备份方式恢复简单，但是恢复还原之后索引会出现错误需要重建，而且备份结果会占据很大的空间，请酌情使用。

三、基于LVM快照实现备份恢复

3.1、思路明细

（1）LVM这种备份方式要求Mysql的数据保存在逻辑卷上

（2）需要给Mysql服务器施加读锁（mysql>FLUSH TABLES WITH READLOCK;），这里不可直接退出服务器

（3）另起终端为数据所在的卷创建快照（lvcreate），保证事务日志和数据文件必须在同一卷上（分别创建可能会导致数据文件和事务日志不一致，从而可能导致无法正常恢复）

3.2、备份策略

LVM快照全备+二进制日志增备（对于即时点恢复还要恢复至后续的二进制位置）

3.3、前提条件

（1）创建逻辑卷及挂载逻辑卷，此过程在此就不做演示了可参考博文

http://pangge.blog.51cto.com/6013757/1256568

（2）初始化mysql将其数据目录指向/mydata/data

1 2	`[root@stu18 ~]` `# cd /usr/local/mysql/` `[root@stu18 mysql]` `# scripts/mysql_install_db --user=mysql --datadir=/mydata/data`

（3）编辑查看配置文件，重启服务

[root@stu18 mysql] # vim /etc/my.cnf

datadir = /mydata/data #查看此项是否定义数据目录位置

sync_binlog=1 #添加此项，每个事务提交时候，把事务日志从缓存区写到日志文件中，并且刷新日志文件的数据到磁盘上；

[root@stu18 mysql] # service mysqld start

3.4、过程展示

（1）确保事务日志和数据文件必须在同一卷上

[root@stu18 ~] # ls /mydata/data/

hellodb myclass mysql-bin.000003 stu18.magedu.com.err

ibdata1 mysql mysql-bin.000004 stu18.magedu.com.pid

ib_logfile0 mysql-bin.000001 mysql-bin.index student

ib_logfile1 mysql-bin.000002 performance_schema test

解析：其中ib_logfile0与ib_logfile1是日志文件

（2）施加全局锁并滚动日志

1 2	`mysql> FLUSH TABLES WITH READ LOCK;` `mysql> FLUSH LOGS;`

（3）查看并保存当前正在使用的二进制日志及当前执行二进制日志位置（非常重要）

mysql> SHOW MASTER STATUS;

+------------------+----------+--------------+------------------+

+------------------+----------+--------------+------------------+

| mysql-bin.000004 | 187 | | |

+------------------+----------+--------------+------------------+

[root@stu18 zhao] # mysql -uroot -pmypass -e 'SHOW MASTER STATUS;' >/zhao/lvmback-2013-08-14/binlog.txt

（4）创建快照卷

1	`[root@stu18 zhao]` `# lvcreate -L 100M -s -p r -n mydata-lvm /dev/vg1/mydata`

（5）立即切换终端释放锁

1	`mysql> UNLOCK TABLES;`

（6）备份数据

1	`[root@stu18 data]` `# cp -a * /zhao/lvmback-2013-08-14/`

（7）二进制实现增量备份

mysql> use hellodb; #指定默认数据库

Database changed

mysql> CREATE TABLE testtb ( id int,name CHAR(10)); #创建表

Query OK, 0 rows affected (0.35 sec)

mysql> INSERT INTO testtb VALUES (1, 'tom' ); #添加数据

Query OK, 1 row affected (0.09 sec)

[root@stu18 data] # mysqlbinlog --start-position=187 mysql-bin.000004 > /zhao/lvmlogbin_2013-08-14/binlog.sql #日志实现增量备份

（8）模拟数据库崩溃

[root@stu18 ~] # service mysqld stop

[root@stu18 ~] # cd /mydata/data/

[root@stu18 data] # rm -rf *

（9）恢复数据

[root@stu18 ~] # cp /zhao/lvmback-2013-08-14/* /mydata/data/ -a #完全备份恢复

[root@stu18 ~] # cd /mydata/data/ #查看恢复数据内容

[root@stu18 data] # chown -R mysql.mysql * #更改属主属组

[root@stu18 data] # service mysqld start #启动服务

[root@stu18 data] # mysql -uroot –pmypass #登录测试

mysql> SHOW DATABASES; #查看数据完整性，无测试表testtd使用二进制恢复

mysql> SET sql_log_bin=0 #关闭二进制日志

mysql> source /zhao/lvmlogbin_2013-08-14/binlog .sql; #二进制恢复

mysql> SHOW TABLES; #查看恢复结果

+-------------------+

| Tables_in_hellodb |

+-------------------+

| classes |

| coc |

| courses |

| scores |

| students |

| teachers |

| testtb |

| toc |

+-------------------+

mysql> SET sql_log_bin=1; #开启二进制日志

此工具是接近于热备的方式实现的，并且用此方法来备份恢复数据速度是非常快的。

四:基于xtrabackup来实现备份恢复

4.1、优势特性

完全以热备的形式进行，能够实现快速可靠地完全备份和部分备份，支持增量备份，支持时间点还原，备份过程中不会打扰到事务操作，能够实现网络传输和压缩功能从而有效的节约磁盘空间，备份完成后可自动验证数据是否可用，恢复速度较快等等。更多优势特性请参考 http://www.percona.com/software/percona-xtrabackup

注意：以上这些优势特性只能在InnoDB引擎上完美实现，而在MyISAM存储引擎上依然最多只能使用温备的形式进行并且还不支持增量备份。

另外Xtrabackup更多的高级功能还依赖于Mysql数据库对于InnoDB实现了单独的表空间，否则也就没有办法实现单表导入导出查看方式如下：

mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_file%' ;

+--------------------------+----------+

| Variable_name | Value |

+--------------------------+----------+

| innodb_file_format | Antelope |

| innodb_file_format_check | ON |

| innodb_file_format_max | Antelope |

| innodb_file_per_table | ON |

+--------------------------+----------+

其中的innodb_file_per_table为ON则表示实现了单表单空间。若为OFF则需要使用mysqldump全备然后更改配置文件删除原来的数据文件并重新初始化服务器最后将数据重新导入。所以建议以后在安装Mysql服务器时将其选项默认设置成1即可（innodb_file_per_table = 1）。单表单空间的数据显示形式为：

[root@stu18 hellodb] # ls

classes.frm coc.MYD courses.MYI scores.MYI teachers.frm testtb.ibd

classes.MYD coc.MYI db.opt students.frm teachers.MYD toc.frm

classes.MYI courses.frm scores.frm students.MYD teachers.MYI toc.MYD

coc.frm courses.MYD scores.MYD students.MYI testtb.frm toc.MYI

4.2、安装Xtrabackup

下载percona-xtrabackup最新的版本为2.1.4（percona-xtrabackup-2.1.4-656.rhel6.x86_64.rpm）

安装：

1	`[root@stu18 ~]# rpm -ivh percona-xtrabackup-` `2.1` `.` `4` `-` `656` `.rhel6.x86_64.rpm`

若有错误无法安装请安装perl-DBD-mysql依赖包

1	`[root@stu18 ~]# yum -y install perl-DBD-mysql`

注意：不同的环境依赖的关系包可能有多个，请依照提示进行配置

4.3、完全备份

使用innobakupex备份时，其会调用xtrabackup备份所有的InnoDB表，复制所有关于表结构定义的相关文件(.frm)、以及MyISAM、MERGE、CSV和ARCHIVE表的相关文件，同时还会备份触发器和数据库配置信息相关的文件。这些文件会被保存至一个以时间命令的目录中。完全备份命令如下：

1	`# innobackupex --user=DBUSER--password=DBUSERPASS /path/to/BACKUP-DIR/`

实现过程及说明：

[root@stu18 ~] # mkdir /innobackup #创建备份文件目录

[root@stu18 ~] # innobackupex --user=root --password=mypass /innobackup/ #完全备份

################如果执行正确其后输出的几行信息通常如下###############

xtrabackup: Transaction log of lsn (1604655) to (1604655) was copied. #二进制日志的位置（lsn）

130814 07:04:55 innobackupex: All tables unlocked

innobackupex: Backup created in directory '/innobackup/2013-08-14_07-04-49' #备份文件保存的位置

innobackupex: MySQL binlog position: filename 'mysql-bin.000003' , position 538898

130814 07:04:55 innobackupex: Connection to database server closed

130814 07:04:55 innobackupex: completed OK! 备份完成

切换至备份文件目录查看备份的数据信息及创建生成的文件：

[root@stu18 ~] # cd /innobackup/2013-08-14_07-04-49/

[root@stu18 2013-08-14_07-04-49] # ls

backup-my.cnf myclass student xtrabackup_binlog_info

hellodb mysql test xtrabackup_checkpoints

ibdata1 performance_schema xtrabackup_binary xtrabackup_logfile

针对文件解析：

(1)xtrabackup_checkpoints —— 备份类型（如完全或增量）、备份状态（如是否已经为prepared状态）和LSN(日志序列号)范围信息；

每个InnoDB页(通常为16k大小)都会包含一个日志序列号，即LSN。LSN是整个数据库系统的系统版本号，每个页面相关的LSN能够表明此页面最近是如何发生改变的。

(2)xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。

(3)xtrabackup_binary —— 备份中用到的xtrabackup的可执行文件；

(4)backup-my.cnf —— 备份时用到的配置选项信息，也就是配置文件中关于mysqld的相关文件配置；

(5) xtrabackup_logfile —— 非文本文件是xtrabackup本身的日志文件；

4.4、准备一个完全备份

一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据文件仍处于不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件从而使得数据文件处于一致性状态。

innobakupex命令的--apply-log选项可用于实现上述功能。如下面的命令：

[root@stu18 ~] # innobackupex -apply-log /innobackup/2013-08-14_07-04-49/

#############如果执行正确，其最后输出的几行信息通常如下################

xtrabackup: starting shutdown with innodb_fast_shutdown = 1

130814 7:39:33 InnoDB: Starting shutdown ...

130814 7:39:37 InnoDB: Shutdown completed; log sequence number 1606156

130814 07:39:37 innobackupex: completed OK!

4.5、模拟数据库崩溃实现完全恢复

（1）模拟崩溃

[root@stu18 ~] # service mysqld stop

[root@stu18 ~] # cd /mydata/data/

[root@stu18 data] # rm -rf *

（2）从完全备份中恢复数据（谨记：在恢复数据之前千万不可初始化数据库和启动服务）

innobackupex命令的--copy-back选项用于执行恢复操作，其通过复制所有数据相关的文件至mysql服务器DATADIR目录中来执行恢复过程。innobackupex通过backup-my.cnf来获取DATADIR目录的相关信息。

[root@stu18 ~] # innobackupex --copy-back /innobackup/2013-08-14_07-04-49/

#############如果执行正确，其最后输出的几行信息通常如下################

innobackupex: Starting to copy InnoDB log files

innobackupex: in '/innobackup/2013-08-14_07-04-49'

innobackupex: back to original InnoDB log directory '/mydata/data'

innobackupex: Copying '/innobackup/2013-08-14_07-04-49/ib_logfile0' to '/mydata/data'

innobackupex: Copying '/innobackup/2013-08-14_07-04-49/ib_logfile1' to '/mydata/data'

innobackupex: Finished copying back files.

130814 07:58:22 innobackupex: completed OK!

（3）当数据恢复至数据目录以后，还需要确保所有数据文件的属主和属组均为正确的用户，如mysql，否则，在启动mysqld之前还需要事先修改数据文件的属主和属组。

1	`# chown -R mysql:mysql /mydata/data/`

（4）启动服务器登陆查看恢复完成。

1	`[root@stu18 data]` `# service mysqld start`

注意：每一次恢复完成之后一定要重新做一次完全备份工作！！

4.6、使用innobackupex进行增量备份

说明：每个InnoDB的页面都会包含一个LSN信息，每当相关的数据发生改变，相关的页面的LSN就会自动增长。这正是InnoDB表可以进行增量备份的基础，即innobackupex通过备份上次完全备份之后发生改变的页面来实现。

第一次改动数据实现增量备份

实现增量备份可以使用下面的命令进行：

1	`[root@stu18 data]` `# innobackupex --user=root --password=mypass --incremental /innobackup --incremental-basedir=/innobackup/2013-08-14_08-14-12/`

其中，/innobackup指的是完全备份所在的目录，此命令执行结束后，innobackupex命令会在/backup目录中创建一个新的以时间命名的目录以存放所有的增量备份数据。--incremental-basedir是指向上一次完全备份所在的目录。

第二次改动数据进行增量备份：

1	`[root@stu18 ~]` `# innobackupex --user=root --password=mypass --incremental /innobackup --incremental-basedir=/innobackup/2013-08-14_08-29-05/`

第二次增量备份的执行命令和第一次大致相同，只有其--incremental-basedir应该指向上一次的增量备份所在的目录。

第三次改动数据还未进行增量备份

1	`mysql> delete from coc where` `id` `=14;`

4.7、使用innobackupex基于完全+增量+二进制日志恢复数据

（1）由于笔者这里将二进制日志和数据文件写在了同一个文件目录下所以在模拟数据库崩溃前必须先复制出二进制日志文件，所以建议看客们将数据目录和二进制目录分开存放，不要和笔者一样犯如此二的错误。方法如下：

前提是在刚刚建立服务器尚未启动服务器之前做如下操作；

mkdir /mybinlog #建立一目录用于存放二进制日志

chown mysql:mysql /mybinlog #更改权限

vim /etc/my .cnf #修改配置文件

log-bin= /mybinlog/mysql-bin #二进制日志目录及文件名前缀，添加之

好了言归正传复制二进制日志文件：

1	`[root@stu18 data]` `# cp mysql-bin.000001/innobackup/`

（2）模拟服务器崩溃

[root@stu18 ~] # service mysqld stop

[root@stu18 ~] # cd /mydata/data/

[root@stu18 data] # rm -rf *

（3）准备备份

首先注意“准备”增量备份与整理完全备份有着一些不同，尤其要注意的是：

1)需要在每个备份(包括完全和各个增量备份)上，将已经提交的事务进行“重放”。“重放”之后，所有的备份数据将合并到完全备份上。

2)基于所有的备份将未提交的事务进行“回滚”。

完全备份“准备”

1	`[root@stu18 ~]` `# innobackupex --apply-log --redo-only/innobackup/2013-08-14_08-14-12/`

第一次增量备份“准备”也就是说将第一次增量备份合并到了完全备份中

1	`[root@stu18 ~]` `# innobackupex --apply-log--redo-only /innobackup/2013-08-14_08-14-12/--incremental-dir=/innobackup/2013-08-14_08-29-05/`

第二次增量备份“准备”也就是说将第二次增量备份也合并到了完全备份中

1	`[root@stu18 ~]` `# innobackupex --apply-log--redo-only /innobackup/2013-08-14_08-14-12/ --incremental-dir=/innobackup/2013-08-14_09-08-39/`

其中 --redo-only是只将已提交的事务同步到数据文件中，未提交的事务日志不在进行回滚了。

（4）恢复数据（基于innobackupex基于完全+增量）

1	`[root@stu18 ~]` `# innobackupex --copy-back/innobackup/2013-08-14_08-14-12/`

（5）更改属组属主

1 2	`[root@stu18 ~]` `# cd /mydata/data/` `[root@stu18 data]` `# chown -R mysql:mysql *`

（6）启动查看

[root@stu18 ~] # mysql -uroot -pmypas

mysql> select * from coc;

+----+---------+----------+

| ID | ClassID | CourseID |

+----+---------+----------+

| 1| 1 | 2 |

| 2| 1 | 5 |

| 3| 2 | 2 |

| 4| 2 | 6 |

| 5| 3 | 1 |

| 6| 3 | 7 |

| 7| 4 | 5 |

| 8| 4 | 2 |

| 9| 5 | 1 |

| 10 | 5 | 9 |

| 11 | 6 | 3 |

| 12 | 6 | 4 |

| 13 | 7 | 4 |

| 14 | 7 | 3 |

+----+---------+----------+

14 rows in set (0.00 sec)

结果显示数据正确完整，但是第三次的改动信息未生效。

（7）基于二进制日志实现数据恢复

查看最后一次增量备份二进制日志所在的位置：

[root@stu18 data] # cd /innobackup/2013-08-14_09-08-39/

[root@stu18 2013-08-14_09-08-39] # cat xtrabackup_binlog_info

mysql-bin.000001 780

查看二进制日志文件将未备份数据的二进制日志导出

[root@stu18 innobackup] # mysqlbinlog mysql-bin.000001

# at 780

#130814 9:20:19 server id 1 end_log_pos 851 Query thread_id=7 exec_time=0 error_code=0

SET TIMESTAMP=1376443219/*!*/;

BEGIN

/*!*/;

# at 851

#130814 9:20:19 server id 1 end_log_pos 944 Query thread_id=7 exec_time=0 error_code=0

SET TIMESTAMP=1376443219/*!*/;

delete from coc where id =14

/*!*/;

# at 944

#130814 9:20:19 server id 1 end_log_pos 1016 Query thread_id=7 exec_time=0 error_code=0

SET TIMESTAMP=1376443219/*!*/;

COMMIT

/*!*/;

DELIMITER ;

# End of log file

ROLLBACK /* added by mysqlbinlog */;

/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

[root@stu18 innobackup] # mysqlbinlog --start-position=780 mysql-bin.000001 > ./all.sql #导出数据

恢复数据

[root@stu18 ~] # mysql -uroot –pmypass

mysql> SET SQL_LOG_BIN=0; #关闭二进制日志

mysql> source /innobackup/all .sql #导入数据

mysql> SET SQL_LOG_BIN=1; #开启二进制日志

mysql> select * from coc; #查看数据，恢复完成

+----+---------+----------+

| ID | ClassID | CourseID |

+----+---------+----------+

| 1 | 1 | 2 |

| 2 | 1 | 5 |

| 3 | 2 | 2 |

| 4 | 2 | 6 |

| 5 | 3 | 1 |

| 6 | 3 | 7 |

| 7 | 4 | 5 |

| 8 | 4 | 2 |

| 9 | 5 | 1 |

| 10 | 5 | 9 |

| 11 | 6 | 3 |

| 12 | 6 | 4 |

| 13 | 7 | 4 |

+----+---------+----------+

13 rows in set (0.00 sec)

这种备份恢复方式完全以热备的形式实现完全备份和增量备份和二进制日志还原数据，并且恢复速度也很快，是最佳的备份恢复方式！！

总结：以上三种备份恢复都是可以基于二进制日志文件进行的，因而体现出了二进制日志的重要性，从而映射出了日志的重要性；所以学习查看使用日志文件是学习Mysql的重中之重！

五、MYSQL的基本操作:增删查改

1、创建数据库： create database <数据库名>；
如：create database student;
2、连接到一个已经存在的数据库： use <数据库名>；
如：use student;
3、删除数据库：drop database <数据库名>；
如： drop database student;
4、创建表：create table <表名>(<列名><列的数据类型>[<列的约束>])
如：create table stuInfo(stuId int primary key,stuName varchar(20) not null)
5、删除表： drop table <表名>
如: drop table stuInfo;
6、修改表：alter table
给表添加新列： alter table <表名> add <列名><列的数据类型>；
添加多列，中间用逗号隔开
如：alter table stuInfo add stuGender varchar(10)
修改某列的数据类型：alter table <表名> modify <列名><新数据类型>
如：alter table stuInfo modify stuGender int
修改列名：alter　table <表名> change <老列名><新列名><数据类型>
如：alter table stuInfo change stuName stuAddress varchar(30)
删除列：alter table <表名> drop <列名>
如： alter table stuInfo drop stuGender
7、将创建的表的语句反向导出： show create table <表名>
8、查询表的所有内容：select * from <表名>
查询表的部分内容： select <列名列表> from <表名>
9、查询表结构：show columns from <表名>
10、插入单行数据：insert into <表名>(<列名列表>) values(<值列表>)
11、插入多行数据：作用相当于将数据从一个表复制到另一个表
insert into <表名> (列名列表) select <select语句>
如将stuInfo表中的所有的学生姓名复制到students表中的stuName列中：insert into students(stuName) select stuName from stuInfo
12、删除数据：delete from <表名> where<过滤条件>
如删除stuID为4的人的数据：delete from stuInfo where stuId=4

六、MYSQL的基本故障判断与处理

以下的文章主要介绍的是 MySQL 常见问题集锦，我们一共分成七大块对其进行说明，我们大家都知道MySQL 数据库在是实际应用中的比例远少于 Oracle，之所是这样的，肯定有它的不足之处。

　　 MySQL常见问题集锦之一：

　　MySQL(和 P HP搭配之最佳组合)总是崩溃

　　首先你应该试着找出问题MySQL(和PHP搭配之最佳组合)d守护进程是否死掉或你的问题是否与你的客户有关。你可以用MySQL(和PHP搭配之最佳组合)adm in version检查你的MySQL(和PHP搭配之最佳组合)d 服务器正常执行了多长时间，如果MySQL(和PHP搭配之最佳组合)d死了，你可以在文件“MySQL(和PHP搭配之最佳组合)-data-directory/ hostname.err”中找到其原因。

　　使用MySQL(和PHP搭配之最佳组合)时的一些常见错误

MySQL(和PHP搭配之最佳组合) server has gone away

　　常见的原因是服务器超时了并且关闭了连接。缺省地，如果没有事情发生，服务器在 8个小时后关闭连接。你可在启动MySQL(和PHP搭配之最佳组合)d时通过设置wait_timeout 变量改变时间限制。

　　如果MySQL(和PHP搭配之最佳组合)d得到一个太大或不正常的包，它认为客户出错了并关闭连接。

Cant connect to [local] MySQL(和PHP搭配之最佳组合) server

　　通常意味着没有一个MySQL(和PHP搭配之最佳组合)服务器运行在系统上或当试图连接MySQL(和PHP搭配之最佳组合)d服务器时，你正在使用一个错误的套接字文件或 TCP/IP 端口。

　　检查(使用ps)服务器上是否有一个名为MySQL(和PHP搭配之最佳组合)d的进程启动

　　如果一个MySQL(和PHP搭配之最佳组合)d进程正在运行，可以通过尝试这些不同的连接来检查服务器

　　shell> MySQL(和PHP搭配之最佳组合)admin version

　　shell> MySQL(和PHP搭配之最佳组合)admin variables

　　shell> MySQL(和PHP搭配之最佳组合)admin -h `hostname` version variables

　　shell> MySQL(和PHP搭配之最佳组合)admin -h `hostname` --port=3306 version

　　shell> MySQL(和PHP搭配之最佳组合)admin -h ip for your host version

　　shell> MySQL(和PHP搭配之最佳组合)admin --socket=/tmp/MySQL(和PHP搭配之最佳组合).sock version

　　注意hostname 命令使用反引号“`”而非正引号“”；这些导致hostname输出（即，当前主机名）被代替进MySQL(和PHP搭配之最佳组合)admin命令中。

Host ... is blocked错误
Host hostname is blocked because of many connection errors.
Unblock with MySQL(和PHP搭配之最佳组合)admin flush-hosts

　　这意味着，MySQL(和PHP搭配之最佳组合)d已经得到了大量(max_connect_errors)的主机hostname的在中途被中断了的连接请求。在max_connect_errors次失败请求后，MySQL(和PHP搭配之最佳组合)d认定出错了(象来字一个黑客的攻击)，并且阻止该站点进一步的连接，直到某人执行命令MySQL(和PHP搭配之最佳组合)admin flush-hosts 。

　　缺省地，MySQL(和PHP搭配之最佳组合)d在 10个连接错误后阻塞一台主机。你可以通过象这样启动服务器很容易地调整它：

shell> safe_MySQL(和PHP搭配之最佳组合)d -O max_connect_errors=10000 &

　　 MySQL常见问题集锦之二：Too many connections错误

　　意味着已经有max_connections个客户连接了MySQL(和PHP搭配之最佳组合)d服务器。

　　如果你需要比缺省(100)更多的连接，那么你应该重启MySQL(和PHP搭配之最佳组合)d，用更大的 max_connections 变量值。

　　 MySQL常见问题集锦之三：Out of m emory错误

　　MySQL(和PHP搭配之最佳组合): Out of memory at line 42, malloc.c

　　MySQL(和PHP搭配之最佳组合): needed 8136 byte (8k), memory in use: 12481367 bytes (12189k)

　　ERROR 2008: MySQL(和PHP搭配之最佳组合) client ran out of memory

　　注意，错误指向了MySQL(和PHP搭配之最佳组合)客户MySQL(和PHP搭配之最佳组合) 。这个错误的原因很简单，客户没有足够的内存存储全部结果。

　　首先检查你的查询是否正确

　　 MySQL常见问题集锦之四：Packet too large错误

　　一个MySQL(和PHP搭配之最佳组合)客户或MySQL(和PHP搭配之最佳组合)d服务器得到一个比max_allowed_packet个字节长的包

　　可以通过用MySQL(和PHP搭配之最佳组合) -- set-variable=max_allowed_packet=8M指定一个更大的缓冲区来启动客户程序。

　　 MySQL常见问题集锦之五：The table is f ull错误

　　这个错误发生在内存临时表变得比tmp_table_size字节大时。

　　Commands out of sync in client错误

　　正在以错误的次序调用客户函数！

　　 MySQL常见问题集锦之六：Ignoring user错误

Found wrong password for user: some_user@some_host; Ignoring user

　　这意味着在MySQL(和PHP搭配之最佳组合)d启动时或在它再次装载权限表时，它在user表中找到了一个有一个无效口令的条目。结果，条目简单地被权限系统忽略。

　　 MySQL常见问题集锦之七： Table xxx doesnt exist错误

　　数据库和表名件是区分大小写的！可以用 SHOW TABLES检b查你在当前数据库中有哪个表。

　　从一个文本文件运行SQL命令

　　可以把SQL命令放在一个文件中并且告诉MySQL(和PHP搭配之最佳组合)从该文件读取其输入：创造一个文本文件“text_file”，它包含要执行的命令。然后如下调用MySQL(和PHP搭配之最佳组合)：

　　shell> MySQL(和PHP搭配之最佳组合) database < text_file

　　或

　　shell> MySQL(和PHP搭配之最佳组合) < text_file

　　启动有USE db_name 语句的文本文件。

　　怎样重新设置一个忘记的口令

　　如果忘记了MySQL(和PHP搭配之最佳组合)的 root 用户的口令，可以使用如下方法恢复：

　　通过发送一个kill（不是kill -9)到MySQL(和PHP搭配之最佳组合)d服务器来关闭MySQL(和PHP搭配之最佳组合)d服务器。p id 被保存在一个.pid文件中，通常在MySQL(和PHP搭配之最佳组合)数据库目录中：

　　kill `cat /MySQL(和PHP搭配之最佳组合)-data-directory/hostname.pid`

　　你必须是一个 UNIX root用户或运行服务器的相同用户做这个。

　　使用--skip-grant-tables 选项重启MySQL(和PHP搭配之最佳组合)d 。

　　用MySQL(和PHP搭配之最佳组合) -h hostname MySQL(和PHP搭配之最佳组合)连接MySQL(和PHP搭配之最佳组合)d服务器并且用一条 GRANT命令改变口令。见7.26 GRANT和REVOKE句法。也可以用MySQL(和PHP搭配之最佳组合)admin -h hostname -u user password new password 进行。

　　用MySQL(和PHP搭配之最佳组合)admin -h hostname flush-privileges或用SQL命令FLUSH PRIVILEGES来装载权限表。

　　使用DATE列的问题

　　DATE值的格式是YYYY-MM-DD 。

　　改变一张表中列的顺序

　　在一个应用程序中，应该决不基于他们的位置使用SELECT * 检索列，因为被返回的列的顺序永远不能保证；对数据库的一个简单改变可能导致应用程序相当有戏剧性地失败。

　　可以使用如下方法改变：

　　以正确的列顺序创建一张新表。

执行INSERT INTO new_table SELECT fields-in-new_table-order FROM old_table.

　　删除或改名old_table 。

A LTER TABLE new_table RE NAME old_table 。

　　数据库复制

　　MySQL(和PHP搭配之最佳组合)(至今)没有数据库复制，但是有一些如何实现的信息。

　　复制一个数据库最一般的方法是使用更新日志。

七、 MYSQL的调优

MySQL调优

调优思路：
1.数据库设计与规划--以后再修该很麻烦，估计数据量，使用什么存储引擎
2.数据的应用--怎样取数据，sql语句的优化
3.mysql服务优化--内存的使用，磁盘的使用
4.操作系统的优化--内核、tcp连接数量
5.升级硬件设备

磁盘io规划
raid技术：raid0[xfs]
swap分区：最好使用raid0
磁盘分区：一个库放到一个分区上或一个磁盘上
物理分区
create table t1(id int,name char(20)) data directory='/data/' index directory ='/data';
mkdir /data
chown mysql.mysql /data

mysql> show variables like '%part%';

4.操作系统的优化
网卡bonding技术，
tcp连接数量限制
优化系统打开文件的最大限制
关闭操作系统不必要的服务

5.mysql服务优化
show status  看系统的资源
show variables  看变量，在my.cnf配置文件里定义的
show warnings   查看最近一个sql语句产生的错误警告，看其他的需要看.err日志
show processlist显示系统中正在运行的所有进程。
show errors

启用mysql慢查询：---分析sql语句，找到影响效率的SQL

log-slow-queries=/var/lib/mysql/slow.log 这个路径对mysql用户具有可写权限
long_query_time=2   查询超过2秒钟的语句记录下来
上面的2 是查询的时间，即当一条SQL 执行时间超过5秒的时候才记录，/var/lib/mysql/slow.log 是日志记录的位置。
然后重新启动MySQL服务

对查询进行缓存
query_cache_size 使用多大内存来缓存查询语句[+8M]
mysql> show variables like'%query%'
query_cache_size=8M
[root@st mysql]# vim /etc/my.cnf

mysql> show status like '%Qcache%';
Qcache_free_blocks：说明缓存太大了。缓存中相邻内存的个数。数目大说明可能有碎片。FLUSH QUERY CACHE会对缓存中的碎片进行整理，从而得到一个空闲块。[+8M]
Qcache_free_memory缓存中的空闲内存
Qcache_hits每次查询在缓存中命中时就增大
Qcache_inserts每插入一个查询时就增大。命中次数除以插入次数就是命中率。
Qcache_lowmen_prunes缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间看；如果这个数字在不断增长就表示可能碎片非常严重，或者内存很少
Qcache_hits/Qcache_inserts 命中率

关键字缓冲区
mysql> show status like '%key%';
mysql> show variables like'key_buffer_size';

key_buffer_size  指定索引缓冲区的大小，它决定索引处理的速度，尤其是索引读的速度。[+8M]
key_read_requests  请求总数
key_reads   代表命中磁盘的请求个数
(key_read_requests-key_read)/key_read_requests：命中率
key_buffer_size只对MyISAM表起作用。即使你不使用MyISAM表，但是内部的临时磁盘表是MyISAM表，也要使用该值。可以使用检查状态值created_tmp_disk_tables得知详情。
对于1G内存的机器，如果不使用MyISAM表，推荐值是16M（8-64M）。

临时表空间大小：order by和group by时把数据放到临时表里。
tmp_table_size   占的是内存的大小，如果太小在排序时会出错
created_tmp_tables  创建临时表的数量
max_tmp_tables=32
tmpdir=/tmp  硬盘上临时表所在的位置
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
innodb表：
创建表空间文件
[mysqld]
innodb_data_file_path=ibdata1:10M:autoextend
这个设置配置一个可扩展大小的尺寸为10MB的单独文件，名为ibdata1。没有给出文件的位置，所以默认的是在MySQL的数据目录内。
如果你对最后的数据文件指定autoextend选项。如果数据文件耗尽了表空间中的自由空间，InnoDB就扩展数据文件。扩展的幅度是每次8MB。
要为一个自动扩展数据文件指定最大尺寸，请使用max属性。下列配置允许ibdata1涨到极限的500MB：
[mysqld]
innodb_data_file_path=ibdata1:10M:autoextend:max:500M
InnoDB默认地在MySQL数据目录创建表空间文件。要明确指定一个位置，请使用innodb_data_home_dir选项。比如，要使用两个名为ibdata1和ibdata2的文件，但是要把他们创建到/ibdata，像如下一样配置InnoDB：
[mysqld]
innodb_data_home_dir = /ibdata
innodb_data_file_path=ibdata1:50M;ibdata2:50M:autoextend

mysql> show variables like 'innodb_buffer_pool_size';
innodb_buffer_pool_size
对于InnoDB表来说，innodb_buffer_pool_size的作用就相当于key_buffer_size对于MyISAM表的作用一样。InnoDB使用该参数指定大小的内存来缓冲数据和索引。对于单独的MySQL数据库服务器，最大可以把该值设置成物理内存的80%。
根据MySQL手册，对于2G内存的机器，推荐值是1G（50%）。

mysql> show variables like 'innodb_%per%';［建议打开］
innodb_file_per_table =1 为每一个表单独创建一个表空间文件。
其他参数
skip-locking
取消文件系统的外部锁，减少出错几率增强稳定性

skip-name-resolve
关闭mysql的dns反查功能。这样速度就快了!
选项就能禁用DNS解析，连接速度会快很多。不过，这样的话就不能在MySQL的授权表中使用主机名了而只能用ip格式。

wait_timeout=10 终止空闲时间超过10秒的链接，避免长连接［默认8个小时］

max_connect_errors=10 //10次连接失败就锁定，使用flush hosts 解锁，
或mysqladmin flush-hosts解锁

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SQL语句调优：
explain命令：查询select。
.type
这列很重要,显示了连接使用了哪种类别,有无使用索引
从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL

-----------------------------

MySQL性能诊断与调优

LAMP 系统性能调优，第 3 部分: MySQL 服务器调优
http://www.ibm.com/developerworks/cn/linux/l-tune-lamp-3.html

LoadRunner监控MySQL
http://www.docin.com/p-92272846.html

Advanced MySQL Performance Optimization
http://www.mysqlperformanceblog.com/files/presentations/UC2005-Advanced-MySQL-

Performance-Optimization.pdf

Improving MySQL Server Performance with Intel C++ Compiler
http://www.mysqlperformanceblog.com/files/presentations/LinuxWorld2005-Intel.pdf

MySQL性能诊断与调优相关工具：
http://www.mysqlperformanceblog.com/tools/
http://hackmysql.com/mysqlreport

Spotlight On MySQL:
http://www.quest.com/spotlight-on-mysql/

Mysql Administator

http://downloads.mysql.com/archives.php?p=MySQLAdministrationSuite

phpMyAdmin

http://www.phpmyadmin.net/home_page/index.php

mysql slow log分析工具
http://hackmysql.com/
http://www.willamowius.de/mysql-tools.html
http://code.google.com/p/mysql-log-filter/
http://myprofi.sourceforge.net/

mysql网络协议嗅探工具 - mysqlsniffer

http://hackmysql.com/mysqlsniffer

MySQL性能诊断与调优相关书籍：
《High Performance MySQL Second Edition》

优化mysql数据库性能的十个参数
(1)、max_connections：
允许的同时客户的数量。增加该值增加 mysqld 要求的文件描述符的数量。这个数字应该增加，否则，你将经常看到 too many connections 错误。默认数值是100，我把它改为1024 。
(2)、record_buffer：
每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描，你可能想要增加该值。默认数值是131072(128k)，我把它改为16773120 (16m)
(3)、key_buffer_size：
索引块是缓冲的并且被所有的线程共享。key_buffer_size是用于索引块的缓冲区大小，增加它可得到更好处理的索引(对所有读和多重写)，到你能负担得起那样多。如果你使它太大，系统将开始换页并且真的变慢了。默认数值是8388600(8m)，我的mysql主机有2gb内存，所以我把它改为 402649088(400mb)。
4)、back_log：
要求 mysql 能有的连接数量。当主要mysql线程在一个很短时间内得到非常多的连接请求，这就起作用，然后主线程花些时间(尽管很短)检查连接并且启动一个新线程。
back_log 值指出在mysql暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。只有如果期望在一个短时间内有很多连接，你需要增加它，换句话说，这值对到来的tcp/ip连接的侦听队列的大小。你的操作系统在这个队列大小上有它自己的限制。试图设定back_log高于你的操作系统的限制将是无效的。
当你观察你的主机进程列表，发现大量 264084 | unauthenticated user | xxx.xxx.xxx.xxx | null | connect | null | login | null 的待连接进程时，就要加大 back_log 的值了。默认数值是50，我把它改为500。
(5)、interactive_timeout：
服务器在关闭它前在一个交互连接上等待行动的秒数。一个交互的客户被定义为对 mysql_real_connect()使用 client_interactive 选项的客户。默认数值是28800，我把它改为7200。
(6)、sort_buffer：
每个需要进行排序的线程分配该大小的一个缓冲区。增加这值加速order by或group by操作。默认数值是2097144(2m)，我把它改为 16777208 (16m)。
(7)、table_cache：
为所有线程打开表的数量。增加该值能增加mysqld要求的文件描述符的数量。mysql对每个唯一打开的表需要2个文件描述符。默认数值是64，我把它改为512。
(8)、thread_cache_size：
可以复用的保存在中的线程的数量。如果有，新的线程从缓存中取得，当断开连接的时候如果有空间，客户的线置在缓存中。如果有很多新的线程，为了提高性能可以这个变量值。通过比较 connections 和 threads_created 状态的变量，可以看到这个变量的作用。我把它设置为 80。
(9)mysql的搜索功能
用mysql进行搜索，目的是能不分大小写，又能用中文进行搜索
只需起动mysqld时指定 --default-character-set=gb2312
(10)、wait_timeout：
服务器在关闭它之前在一个连接上等待行动的秒数。默认数值是28800，我把它改为7200。
注：参数的调整可以通过修改 /etc/my.cnf 文件并重启 mysql 实现。这是一个比较谨慎的工作，上面的结果也仅仅是我的一些看法，你可以根据你自己主机的硬件情况（特别是内存大小）进一步修改。

八、 MYSQL主主、主从复制的实现

见SVN文档

九、MYSQL大数据备份和恢复

见SVN文档

十、数据文件的损坏与修复

1.       表损坏的原因分析
以下原因是导致mysql 表毁坏的常见原因：
1、服务器突然断电导致数据文件损坏。
2、强制关机，没有先关闭mysql 服务。
3、 mysqld 进程在写表时被杀掉。
4、使用myisamchk 的同时，mysqld 也在操作表。
5、磁盘故障。
6、服务器死机。
7、 mysql 本身的bug 。

2.       表损坏的症状
一个损坏的表的典型症状如下：
1 、当在从表中选择数据之时，你得到如下错误：
Incorrect key file for table: '...'. Try to repair it
2 、查询不能在表中找到行或返回不完全的数据。
3 、Error: Table 'p' is marked as crashed and should be repaired 。
4 、打开表失败： Can’t open file: ‘×××.MYI’ (errno: 145) 。
5 、

3.       预防 MySQL表损坏
可以采用以下手段预防mysql 表损坏：
1 、定期使用myisamchk 检查MyISAM 表（注意要关闭mysqld ），推荐使用check table 来检查表（不用关闭mysqld ）。
2 、在做过大量的更新或删除操作后，推荐使用OPTIMIZE TABLE 来优化表，这样既减少了文件碎片，又减少了表损坏的概率。
3 、关闭服务器前，先关闭mysqld （正常关闭服务，不要使用kill -9 来杀进程）。
4 、使用ups 电源，避免出现突然断电的情况。
5 、使用最新的稳定发布版mysql ，减少mysql 本身的bug 导致表损坏。
6 、对于InnoDB 引擎，你可以使用innodb_tablespace_monitor 来检查表空间文件内文件空间管理的完整性。
7 、对磁盘做raid ，减少磁盘出错并提高性能。
8 、数据库服务器最好只跑mysqld 和必要的其他服务，不要跑其他业务服务，这样减少死机导致表损坏的可能。
9 、不怕万一，只怕意外，平时做好备份是预防表损坏的有效手段。

4.       MySQL表损坏的修复
MyISAM 表可以采用以下步骤进行修复：
1、使用 reapair table 或myisamchk 来修复。
2、如果上面的方法修复无效，采用备份恢复表。

具体可以参考如下做法：
阶段1 ：检查你的表
如果你有很多时间，运行myisamchk *.MYI 或myisamchk -e *.MYI 。使用-s （沉默）选项禁止不必要的信息。
如果mysqld 服务器处于宕机状态，应使用--update-state 选项来告诉myisamchk 将表标记为' 检查过的' 。
你必须只修复那些myisamchk 报告有错误的表。对这样的表，继续到阶段2 。
如果在检查时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。
阶段2 ：简单安全的修复
注释：如果想更快地进行修复，当运行myisamchk 时，你应将sort_buffer_size 和Key_buffer_size 变量的值设置为可用内存的大约25% 。
首先，试试myisamchk -r -q tbl_name(-r -q 意味着“ 快速恢复模式”) 。这将试图不接触数据文件来修复索引文件。如果数据文件包含它应有的一切内容和指向数据文件内正确地点的删除连接，这应该管用并且表可被修复。开始修复下一张表。否则，执行下列过程：
在继续前对数据文件进行备份。
使用myisamchk -r tbl_name(-r 意味着“ 恢复模式”) 。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件。
如果前面的步骤失败，使用myisamchk --safe-recover tbl_name 。安全恢复模式使用一个老的恢复方法，处理常规恢复模式不行的少数情况( 但是更慢) 。
如果在修复时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。
阶段3 ：困难的修复
只有在索引文件的第一个16K 块被破坏，或包含不正确的信息，或如果索引文件丢失，你才应该到这个阶段。在这种情况下，需要创建一个新的索引文件。按如下步骤操做：
把数据文件移到安全的地方。
使用表描述文件创建新的( 空) 数据文件和索引文件：
shell> mysql db_name
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE tbl_name;
mysql> quit
如果你的MySQL 版本没有TRUNCATE TABLE ，则使用DELETE FROM tbl_name 。
将老的数据文件拷贝到新创建的数据文件之中。（不要只是将老文件移回新文件之中；你要保留一个副本以防某些东西出错。）
回到阶段2 。现在myisamchk -r -q 应该工作了。（这不应该是一个无限循环）。
你还可以使用REPAIR TABLE tbl_name USE_FRM ，将自动执行整个程序。
阶段4 ：非常困难的修复
只有.frm 描述文件也破坏了，你才应该到达这个阶段。这应该从未发生过，因为在表被创建以后，描述文件就不再改变了。
从一个备份恢复描述文件然后回到阶段3 。你也可以恢复索引文件然后回到阶段2 。对后者，你应该用myisamchk -r 启动。
如果你没有进行备份但是确切地知道表是怎样创建的，在另一个数据库中创建表的一个拷贝。删除新的数据文件，然后从其他数据库将描述文件和索引文件移到破坏的数据库中。这样提供了新的描述和索引文件，但是让.MYD 数据文件独自留下来了。回到阶段2 并且尝试重建索引文件。

InnoDB 表可以采用下面的方法修复：
如果数据库页被破坏，你可能想要用SELECT INTO OUTFILE 从从数据库转储你的表，通常以这种方法获取的大多数数据是完好的。即使这样，损坏可能导致SELECT * FROM tbl_name 或者InnoDB 后台操作崩溃或断言，或者甚至使得InnoDB 前滚恢复崩溃。尽管如此，你可以用它来强制InnoDB 存储引擎启动同时阻止后台操作运行，以便你能转储你的表。例如：你可以在重启服务器之前，在选项文件的[mysqld] 节添加如下的行：
    [mysqld]innodb_force_recovery = 4innodb_force_recovery 被允许的非零值如下。一个更大的数字包含所有更小数字的预防措施。如果你能够用一个多数是4 的选项值来转储你的表，那么你是比较安全的，只有一些在损坏的单独页面上的数据会丢失。一个为6 的值更夸张，因为数据库页被留在一个陈旧的状态，这个状态反过来可以引发对B 树和其它数据库结构的更多破坏。
    1 (SRV_FORCE_IGNORE_CORRUPT)
即使服务器检测到一个损坏的页，也让服务器运行着；试着让SELECT * FROM tbl_name 跳过损坏的索引记录和页，这样有助于转储表。
    2 (SRV_FORCE_NO_BACKGROUND)
阻止主线程运行，如果崩溃可能在净化操作过程中发生，这将阻止它。
    3 (SRV_FORCE_NO_TRX_UNDO)
恢复后不运行事务回滚。
    4 (SRV_FORCE_NO_IBUF_MERGE)
也阻止插入缓冲合并操作。如果你可能会导致一个崩溃。最好不要做这些操作，不要计算表统计表。
    5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
启动数据库之时不查看未完成日志：InnoDB 把未完成的事务视为已提交的。
    6 (SRV_FORCE_NO_LOG_REDO)
不要在恢复连接中做日志前滚。
    数据库不能另外地带着这些选项中被允许的选项来使用。作为一个安全措施，当innodb_force_recovery 被设置为大于0 的值时，InnoDB 阻止用户执行INSERT, UPDATE 或DELETE 操作.
    即使强制恢复被使用，你也可以DROP 或CREATE 表。如果你知道一个给定的表正在导致回滚崩溃，你可以移除它。你也可以用这个来停止由失败的大宗导入或失败的ALTER TABLE 导致的失控回滚。你可以杀掉mysqld 进程，然后设置innodb_force_recovery 为3 ，使得数据库被挂起而不需要回滚，然后舍弃导致失控回滚的表。

科技创业公司的效率工具箱

Thu, 20 Nov 2014 16:15:47 CST

如何保持效率，不仅仅是个人的挑战，这对一个组织或公司而言也至关重要，这也与公司的信息流动和沟通交流密切相关。在科技型创业公司，效率会变得更致命，因为这些公司通常都运作得非常快，而且还常常面临着巨大的压力（例如产品发布日期，资金的运转等）。

所以，这就需要在创业公司所有成员之间要保持高度的一致性，去确保产品适应市场，后期的平稳运行，和公司的整体透明度。

在 Worktile 这一年的创业旅程中，我们遇到很多值得学习的优秀产品，我们也希望将Worktile打造成一款优秀的效率工具，再这里，我们希望将我们这一年的经验和我们认为非常值得使用的工具分享给大家。

在我们开始之前，我们首先要明确典型的科技初创公司的几点需求：基本上，一般有四种需求：

1.团队内部以及与外部的沟通需求；

2.用于跟踪和协调的工作流程和任务的需要；

3.提升协作效率的需求；

4.扁平化和足够的透明度。

5.Toolbox for Tech Startup

Slack for 沟通 好吧，我承认，最近快要被 Slack 各种叼爆天的新闻刷屏了。但追求极致，简单干脆满足人类沟通需求的 Slack 确实太有魅力。在Slack中你可以跟你的团队成员进行高效的内部沟通，还可以对团队成员以及各成员分享的文件，文档进行搜索。你可以创建一些基于你们需要讨论各种话题的工作和任务，也可以有专门的主题内容，如聚会，开发，设计等等。除了这些，Slack 还整合了 Twitter、Zendesk、Crashlytics 和 Heroku 等服务，将它们的通知提醒、Bug 追踪等数据融入到公司内的信息流中。让整个公司的内部交流只关注于跟工作有关的信息流，极大地提高了沟通效率。就像 Slack 的 Slogan 一样： Be less busy！

文件存储的 Dropbox Dropbox 在存储方面展现的魅力已无需多言（对 Tech Startup 来说，被墙完全不是个问题好吧）全世界数以亿计的用户正在使用Dropbox，这可以让我们在电脑、手机、平板，甚至服务器上同步、备份或共享文件资料。文件的管理与共享在团队效率方面有着最明显的表现，版本控制，文件查找再也不会成为绊脚石了。

针对中小团队的团队协同工具 Worktile Worktile ，正是我远程实习的一家科技创业公司，是面向中小团队的协同工具。提倡通过任务驱动来连接团队在执行项目的过程中的事和事，人和事，人和人。在实习过程中，我们之间的任务分配和协调工作都是在 Worktile 上完成的。在 Worktile ，你可以根据公司不同的部门创建不同的项目，如“店小二”的运营部，苦逼的开发部等。得益于 Worktile 的看板式任务列表和不同层级权限管理机制，我们的工作效率得到大大的提升，知道Worktile每两周甚至每周就升级版本的秘诀么？就是Worktile带给我们的：不知不觉就提高了工作效率。如果正打算使用Worktile，那么，上吧！你将享受到一种前所未有的协同工作方式，就算是异地办公也是毫无压力（PS：我就是异地办公）。还有一点就是，Worktile有一个非常有爱的用户社区，你可以在社区提一些建议或者分享一些关于协同工作的干货等，而一旦你在社区发帖，我们Worktile的官方人员会竭诚为你“秒回”！这个得点32个赞！快来点赞

可爱的大象头 Evernote 在我看来是一个更偏向于个人使用的工具，我们团队中很多人也是它的付费用户，主要是负责管理一些私人的日记和记录一些牛逼的灵感，在产品上，Evernote 的极致追求我们作为用户是切实的感受到了！我最初使用Evernote是在2012年，当时Evernote已经宣布对所有用户提供最基础免费空间和功能。而在全平台支持的Evernote上，我一般使用的是Web版，因为对于我个人来说，我使用Evernote的时候无非就是编辑一下日记而已，没用上很多Evernote在微信推送的高大上功能，所以我基本是懒得下PC端，直接在Web上使用就很完美。

在线作图工具 ProcessOn ProcessOn是国内目前做得比较好的在线作图协作平台。在创业的过程中，难免会有一些图表，像流程图，图表式的Roadmap等，既然我们的重心是在产品上，那么我向你推荐ProcessOn，它可以快速地制作出你想要的各种图。而且，ProcessOn还支持协作画图，你可以跟你的小伙伴们一边作图，一边沟通交流。这不是跟我们倡导的理念一样么？哇哈哈。

大百度的思维导图百度脑图 百度脑图的功能不算很多，但足够日常使用了，我通常是在总结工作和理清代码思路的时候用它。优点蛮多：支持随处拖拽，云储存，不占用硬盘空间，一键分享给你们的小伙伴，你甚至还可以导入百度的Doc文件……而其中最赞的功能莫过于百度脑图支持多格式保存文件，你既可以到出成「.xmind」格式，也可以导出成「.mm」格式，也可以导出成「.km」格式……这样导出的思路脑图就可以在你的电脑客户端完美进行在编辑了，如果你需要的话。 （大百度也还是有如此精致的产品嘛）

PDF Word Excel转换 Convertii 我只是默默将这个链接分享给你。这样的工具有很多，但首先还是推荐这个，界面简洁，支持直接拖拽文件上传等，各种用户体验都非常好，你可以「PDF转Word」，还可以转Excel，转Text等。你不用安装任何Adobe Acrobat XI Pro或者类似的软件了，直接将文件拖入到这个网页的就可以见证奇迹了。Yeah~~~

数据统计可视化工具 infogr.am infogr.am 是一个很强大的数据可视化图表创作平台，这是我老大@小泽马君给我推荐的工具，你可以在上面创建很多种表格，包括常见的圆饼图，条形图，柱状图和一些炫酷吊炸天信息图表（一共14种）。还在为数据可视化烦恼？小白不懂D3.js？不用怕，现在你只要注册一个 infogr.am账号可以分分钟创作出各种亮瞎的数据图表了。这对于一些产品经理来说不就是一个开挂的工具么？不过……它不是免费的，你可能需要每月交上几美元。

Defonic for Relax

说了这么多生产工具，最后分享一个让你放松的网站： Defonic ,我通常会在工作累了的时候或者有时候直接一边写东西一边放背景音乐。这是一个能产生环境音效的线上服务，公提供24种不同的环境声音，包括海洋、河流、雨滴、森林、篝火、闪电、风声、夜晚、浪涛等等，你无需下载或暗转任何软件，只要将网页打开，点击你想播放的声音按钮就行。

Tips: Defonic 默认情况下是不显示背景的高清大图的，你需要点击右上的HD小按钮才会出现如此的身临其境的图片。

整体来说，Defonic 提供的音效品质相当好，即使有背景音乐搭配播放，也不会有很吵杂、难以忍受的感觉。强烈推荐各种设计师，工程师到上面放松自己

痛并快乐着

对于怀揣着梦想的创业者们，大家享受着这旅程上的一切惊奇与喜悦，也承担着巨大压力与质疑。我们希望将这些实用的工具分享给大家，多少可以减轻些工作中的负担，减少重复性工作，将精力放到更加重要的或者我们更享受的事情上，拼尽全力的去追寻各自心中的秘宝！

科技创业公司的效率工具箱，首发于博客 - 伯乐在线。

要想提高工作效率，请拒绝做这7种事

Fri, 25 Jul 2014 12:51:24 CST

编者注：此文是 CamMi Pham 的文章，原文发表在 Medium上。作者通过自身经历和一些科学证据说明，有时候努力工作未必是通往成功的正确路径。成功的关键不是努力而是巧干。因为时间是稀缺商品，有时候少干反而收效更佳。

忙未必就说明你有生产力。要想有生产力，更多的是要管理好你的精力而不是时间。要经营好你的生活。我们需要学会花费最小的精力得到最大的收益。不干以下 7 件事，我把每周的工作时间从 80 小时缩短到了 40 小时，但是完成的工作却多了很多。

1、不加班效率高

每周 5 天，每天 8 小时的工作制是福特在 1926 年的发现。实验表明，把每天工作时间从 10 小时降至 8 小时，每周工作时间从 6 天降至 5 天后，生产力反而提升了。

1980 年由商业圆桌会议发布的《建筑项目的加班效应》指出，无论从短期还是长期来看，工作越多，效率和生产力都会下降：

若每周工作时间超过 60 小时的情况持续超过两个月，生产力下降的累积效应将导致完工日期推迟，而同样的人数每周只工作 40 小时甚至还会更早完工。

美国军方研究表明，“每天少睡 1 小时持续一周会导致相当于 0.1 血醇水平的认知退化”。

《睡眠的秘密世界》指出：

熬夜之后无论白天你干得有多好，情绪不会太高。更重要的是前瞻性思考和行动的意愿、对冲动的抑制、乐观程度、同理心、情商等也会下降。

所以保证充足的睡眠对于维持高水平的生产力十分重要。

很多名人的经验是白天多小睡。达芬奇、拿破仑、爱迪生、罗斯福夫人、吉恩•奥特里、肯尼迪、洛克菲勒、丘吉尔、林顿•约翰逊、里根等都有小睡的习惯。

2、不要老说“好的”

根据 20/80 原理（帕累托原理），20% 的努力创造出 80% 的结果；但反过来 20% 的结果消耗了 80% 的努力。因此我们应该把精力集中在能产出 80% 结果的事情上，然后放弃其他的事情。如此就能把更多的时间集中在最重要的任务上。我们应该对低产出甚至无结果的任务停止说“yes”。

成功人士和非常成功人士的区别在于后者几乎对所有事情说“不”

——巴菲特

这就引出一个问题：我们该对哪些事情说“yes”，对哪些事情说“no”呢？如果想不出哪些事情值得花时间，不妨来个简单的分离测试。跟踪自己所做的一切事情然后尽可能优化。

我们中的大多数往往都说了太多的“yes”，因为这比拒绝要容易得多。没人想当坏人。

2012 年的消费者杂志发表了一项研究，研究人员把 120 人分成了 2 组。一组人训练成说“我不能（I can’t）”，另一组则说“我不（I don’t）”。结果很有趣：

告诉自己“我不能吃 X”的学生在 61% 的时间内选择了吃巧克力糖，而告诉自己“我不吃 X”的只在 36% 的时间里抵挡不住诱惑。在说法上作这么简单的一个变化就能显著改善健康食品的选择。

所以，下次需要避免说 yes 的时候，直接说“我不”。

另一个避免不必要活动的技巧是 20 秒规则：对于不应该做的事情多给自己 20 秒的时间考虑。

3、不要事必躬亲

我曾经管理过一个非常大的社区，试图一个人做完所有事情，最后发现我干不了。我筋疲力尽，最后社区接管了自我管理的工作。令人惊奇的是大家做得比我还好。我因而领悟到了社区的力量。

我们必须意识到，在需要的时候可以去寻求帮助，这一点很重要。让做得更好的人接管你的一些工作对你来说更好。这可以让你花更多的时间在自己最重要的任务上。不要把时间浪费在自己解决问题上，让专家帮助你。

很多时候，哪怕朋友不能帮你，他们的陪伴也能让你更有生产力。

4、不要完美主义

达尔豪斯大学的心理学教授 Simon Sherry 的完美主义与生产力研究发现，完美主义是生产力的绊脚石：

完美主义者完成任务需要花费更多的时间

完美主义者因此等待完美时刻而耽搁。就商业而言，如果你等到了完美时刻时间已经太迟。

完美主义往往因为一叶障目而不见泰山，因为过于关注小事情而错失了大场面。

最好的完美时刻就是现在。

5、不要做重复工

根据 Tethys Solution 的一项研究，一支 5 人团队，如果把 3%、20%、25%、30% 和 70% 时间花在重复性工作上，经过 2 个月的生产力强化（引入自动化软件）后，时间相应降至 3%、10%、15%、15% 和 10%。

现在只要我需要重复做一件事情 5 次以上，我就会要求自己找个程序来替我做。不会编程没关系，如果不懂开发，那就去买程序。

人们往往不记得时间就是金钱。他们手工做的原因通常是因为这么做比较容易，不需要研究。处理 30 张图片似乎没有问题，但是如果是 30000 张呢？你只能靠软件去处理了。记住，你需要花钱去挣钱，而时间是你最有价值的商品。

6、决策不靠猜测

如果网站可以 SEO，那么生活也能。不要靠胡乱猜测做决定，要用数据支持你的决策。

不同领域有许多研究可供参考。比方说，你是否知道下午 4 点的时候人最容易分心？这是宾州大学助理教授 Robert Matchock 领导的一项研究。哪怕你找不到需要的数据，进行分离测试也不需要话太多的时间。

要不断问问自己，你打算如何去衡量和优化自己所做的一切事情？

7、不要老是工作

大多数人没有意识到，如果我们过于专注在某件事情上，就会画地为牢，跳不出框框。时不时从工作中脱身出来独处一下非常重要。按照《孤独的力量》的说法，独处的时间对于大脑和精神很有益处：

哈佛研究表明，如果某人相信自己正在独自体验某件事情时，其记忆会更持久更精确。另一项研究表明，一定时间的独处可令人更具同理心。尽管没人会质疑早期过多的孤僻生活是不健康的，但一定时间的独处可令青少年改善情绪提高成绩。

给反省留点时间很重要。当我们不去寻找解决方案时，后者却往往不期而至。

当然，我们不能一夜之间就能变得更有生产力。跟生活中的每一件事情一样，这也需要努力。守株待兔是等不到变化的。我们都需要多了解自己的身体，找到精力分配的最佳方式，这样才能拥有更成功更幸福的生活。

企业开发的互联网转型

Fri, 04 Jul 2014 23:00:14 CST

算起来，我从互联网开发转向企业开发已经有四年时间了。在刚刚投身企业开发的那段时间，虽然也读过《企业应用架构模式》之类的书，到底没有做过正经的“企业开发”，而且业务并不算太复杂，所以还是借着之前互联网开发的老底子解决问题。这么做确实解决了很多问题，但心里还不太放心，总觉得这不是名正言顺的“企业开发”，以后会有问题。

因为谈到传统的企业开发，大家通常想到的是重型的框架、瀑布模型、严格的限制、海量的文档和签字、对商用软件的倚重等等（正版盗版另论）。而谈到互联网开发，大家通常想到的是轻量的开发、迅速迭代、不断的试错、面对面的交流、开源/免费软件的广泛使用。传统上，企业开发和互联网开发并不对付，你觉得我是杂乱无章的恣意胡闹，我觉得你是傻大笨粗的因循守旧，好在双方“井水不犯河水”，也相安无事。

企业开发和互联网开发的这种区别，也是我在跨界之时的一大忧虑。然而工作得越久，事实却不断证明这种担心是多余的，或者至少不必高估“企业开发”的正统性。而且，有越来越多的迹象让我相信，企业开发的互联网转向，是未来的趋势。按照我的总结，原因大致有以下几点。

首先，经济的发展诞生了越来越多的小企业，而信息化的发展已经让IT成了各种企业的必须，所以“企业开发”必须考虑到这些小企业的需求。前些年大家开个饭馆、书店，可能手工记账即可。现在哪家饭馆、哪家书店没有IT系统，简直是不可想象——哪怕这种IT系统是非常简单的程序。尤其是在电子商务兴起之后，众多企业都希望上网展示自己、拓展业务，这时候更少不了IT系统。这些小企业只关心简单、便宜、易用的IT系统，传统的重型“企业开发”并不能适应它们的需求。即便其业务增长迅速，这种业务通常也是创新型的业务，没有现成的企业系统能够适应，所以互联网开发模式下轻量级的、能迅速迭代的系统，更能满足需求。

其次，企业开发已经很难吸引到优秀的人才加盟。最早的软件开发几乎等于“企业软件开发”，一招一式皆有成为规范可循，而互联网开发更像是半路出家，“摸着石头过河”的产物，一早并不被科班所重视。所以之前定义的“好学生”，往往是理论学得扎实、教材读得仔细、工具用得熟练的人。企业开发的套路正好又和学校学的一致，所以“好学生”往往能成为企业开发的优秀人才。如今的情况却大不相同，“好学生”嘴里谈的更多的，也更感兴趣的，可能是MongoDB、Node.js、Ruby on Rails、Go等等新鲜玩意。别说“老派的”WebService、Struts，甚至就连.NET MVC、Spring估计都不能引起他们的兴趣。加之传统从事企业开发的人对技术的保守特性（更愿意采用成熟技术），直接灭绝了大量人才（包括优秀的苗子）进入企业开发领域的可能性，而没有新鲜血液补充的企业开发团队，不说开发新功能，维护的成本都会日益增高。我曾经遇到过客户仍在使用Delphi开发的系统，可惜已经很难找到人维护了。

再次，移动办公的应用场景所倚赖的技术离不开互联网。传统的企业开发，无论Java平台还是.NET平台，与如今流行的移动开发基本是“绝缘”的。企业开发所使用的COM、SOAP、WSDL等等技术，在iOS、Android开发者看来，简直是天方夜谭，即便费劲周折，也不一定能取得好的效果。然而企业开发分明又面临着支持移动平台、移动办公的压力，如果固守之前的套路和技术，只有死路一条。

最后，如今的互联网已经越来越讲究互连互通了，传统企业开发的“闭环”思维和模式，已经越来越不适应时代的要求。我接触的很多客户、合作方，发现企业系统的一大问题是信息孤岛效应。或许两家企业都有各自的信息系统，而且运行流畅稳定，可是一旦需要进行数据交流则叫苦不迭。因为没有合适的对外接口，要么就冒很大风险开放不必要的权限，要么就只能通过QQ或邮件手工交换数据。在互联网开发的人看来，世界天生是由无数API构成的，这样才有无限想象空间；但对很多从事企业开发的人来说，别说对外的接口，就是对内的接口都很难做，大家更习惯为着确定目的“量身打造”紧耦合的系统。

不能互连互通的另一大问题在于，互联网、云计算，已经为以前麻烦的众多问题提供了低成本的解决方案。比如困扰许多企业系统的存储问题，传统的解决办法大概是去买专门的存储设备，购置费用一大笔不说，支持和维护的支出更是没有尽头。但是同样的问题，在互联网上已经有非常成熟的解决方案，存储的价格相当低廉，很适合存储海量的非敏感业务数据（如果不信任国内的云服务商，可以存放在亚马逊的S3，也可以分几家存储）。如果不能采用类似的方案，必然要求企业系统的开发者“亲力亲为”地解决这种问题，分散了本该聚焦在核心业务上的注意力。

当然，传统的企业开发方式里，还是有很多有意义而且值得保留的做法，比如明确的目标设定、详细的需求管理、规范的进度把握等等。我曾在知乎看到有人评价说“互联网有时给人的感觉是太杂乱无章了，有时根本不按规矩来，而要真正做好一件事情，基本的规矩是必须要遵守的”，这种观点我很认同。但是总的来说，企业开发从传统的“企业开发模式”转向“互联网开发模式”，是“不得不为”的趋势。我心中理性的企业开发，应当是在“专心关注核心业务”之外，广泛、合理地应用外界各种开发技术和资源的模式。各位身处企业开发领域，但还没有足够资本退休的朋友，或许该早早做准备了。

管理者塑造創新公司文化的六個方法

Wed, 15 Jan 2014 19:11:11 CST

圖片來源： Thomas Hawk。

讓員工有時間思考，同時提供他們需要的思考架構。

公司結構設計成怎麼樣，公司未來就會怎麼樣發展。經驗老道的領導者將他們的公司形塑成驅動創新的文化，這些領導者們知道他們的公司文化──價值、成規、潛在訊息、以及領導者和員工行為的潛規則。事實上，70% 組織變革的失敗都是由這些看不見的力量所致。那麼，塑造創新公司文化的技巧是什麼呢？就是要規劃出公司內員工彼此之間互相產生關聯的方式，以及員工和公司產生關聯的方式。以下有六個明顯的策略方向：

1. 清楚意識到您的創新意圖

大多數的公司願景和任務聽起來都超級相似：成為XXX、XXX 的第一名。這些籠統、大範圍的目標可能可以煽動銷售團隊，但他們很少會將工作做得別出心裁。大概是因為一個公司所能做的一個最糟糕的事情就是設立一個「創新」的員工守則，但卻沒有給予明確的指引。這就是團隊開始失焦、原地打轉的時候。

2. 為彈性的工作時間設計一個架構

創新需要時間來發展。員工從未曾經感到有多餘的時間，人們大多數的時間都在救近火和追逐短期目標，大部分的人無法去設想未來。當壓力到極大點時，放棄控制──是完美創新的悖論（paradox）。這也就是為什麼指標性的公司，如 3M 和 Google 給予他們員工 10% 的自由時間用以讓員工嘗試、檢驗自己的新想法。軟體公司 Atlassian 鼓勵員工放假（稱放 FedEx 假，帶薪的自由時間），來處理他們想要解決的任何問題。但也有一個條件：例如 FedEx 員工要在放了假以後需要交上一些成果。 Intuit 公司就用時間當作獎勵，因為他們相信一個公司的內部創業者的最大工作動機便是時間。Intuit 給予它最好的企業創新者 3 個月的「自由」工作時間，可以決定要整塊使用或者將時間平均分散到 6 個月使用。因此，策略性地善用時間，創造出工作的主要誘因。

３、涉入，然後再把手收回去

提供員工免費時間來試驗新科技、產品，或催化下一個偉大產品的過程。但太多的公司──與他們曾經聘請的諮詢師──過度策劃創新的過程。更好的作法是： 提供人們剛剛好的架構和支持，幫助他們在不確定中找到方向，並以不會過度壓迫的方式干涉創意過程。 這裡有一些非常好的現成工具幫助員工發展出技能組合（skill set）。有一些最好的工具甚至是免費使用的，例如史丹佛大學設計研究所的 Boot Camp Bootleg。 Intuit 運用史丹佛模式的內涵──設計思考──創造出 Catalyst Toolkit，一個所有員工以及大眾都可取用的指南，包含能如法炮製創新的自助自學元素。從軟體工程師到人資經理，都已經使用這個工具箱輔助內部工作過程的創新，或創造新產品，包含 SnapTax 這個能夠讓使用者在 15 分鐘內於手機繳稅的產品。公司應提倡這些類型的工具箱，幫助說服員工：老闆很關心他們的開發過程，同時也鼓勵個人或團隊可以彈性順應自己的步調作最佳的工作實踐。

圖片來源： nyoin。

4. 測量什麼是有意義的

管理大師彼得‧杜拉克曾經說過「有被測量的東西都會改善。（What’s measured improves.）」換句話說，您測量什麼您就會獲得什麼。對許多公司來說，想出點子通常不是問題所在。挑戰在於將這些點子化為現實，並發揮影響力。所以，這樣的公司該使用什麼指標呢？第一、要先想清楚要測量的東西是什麼。在早期，Facebook 測量使用者多久回訪網站一次。他們所作的所有事情都聚焦在發展這一個單一指標。餐廳預定服務 OpenTable 僅著重在兩個指標，讓它能夠變成市場巨頭：提升（1）其網絡中的餐廳數量，以及增加（2）在 OpenTable 預訂餐廳的顧客數量。我們可以了解顧客導向的數字非常關鍵。但其他指標同樣可以驅動內在創新。當 Proctor & Gamble 意識到合作聯盟關係對驅動市場突破創新的重要性之後，他們決定測量（並增加）自家新產品使用合作夥伴突破性技術的數量，從 10% 增加到 50% 以上，外在地驅動創新，因而創造出了 Mr. Clean Magic Erasers 與 Tide Pods 等的新產品。其他可以驅動組織創新的指標包括：

從產品或服務推出後一個期間內（例如上個會計年度）的營利百分比。
新點子的系統化產出量，包括「短期產品或服務的點子」與「長期性的改變市場規則的點子」之間的比例（例如 75%-25%）。
有經過訓練的員工或者曾給予創新工具的員工的百分比。
花費在發現、製作原型、試驗新產品、服務或商業模式的百分比（例如總工時的 10-20% ）。

圖片來源： las - initially。

5. 給予「無實質價值」的報酬

認可表揚員工的成功，是關鍵的行為，但大部分的公司就停在這裡了。一個年度創新的獎項不足以促進創新文化。當然，正式的獎項在短期有不錯的效果──但事實上它卻沒有讓人們真正且不斷地投入創新。最強而有力的認可是──能夠塑造公司價值的那種──通常它的發生是非正式的。Colgate-Palmolive 的 Global R&D 團隊提倡一種「認可的經濟」，透過將象徵性的木製鎳幣分發給在其工作領域有顯著貢獻的同事，然而，收到鎳幣的人不會囤積他們贏得的東西，他們將它傳給其他人。雖然鎳幣主要會議上遞送，但對員工來說，午餐後回來在公司抽屜裡面發現幾個鎳幣是不足為奇的事。這是一個有趣且有用的點子；類似的非正式認可，激勵了團隊精神並幫助提倡點子的自由流動。

6. 象徵化

象徵可以代表組織的潛在價值，它們可以在很多種形式中出現──價值宣言、獎項、成功故事、走道上的海報、標語、縮寫，當然，木質鎳幣也是。刻意在公司內部策展創新象徵的人，基本上是策展他們的創新文化。 Intuit 將象徵設定在廚房餐桌上，這個地點是 Scott Cook 和他的妻子夢想的創新中心──員工被鼓勵在餐桌旁邊坐下，思考新的點子。 Netflix 將其公司會議室用熱門電影來命名（其中有一個是「金剛」），提醒員工持續地在創造以及推廣的過程中突破。但象徵符號所代表的超過物質本身。舉例來說，故事和民俗傳說中都有淒美的經驗。象徵，形塑了新進與現有員工的心態。在 Google, Sheryl Sandberg 作了一個錯誤決策使 Google 損失慘重的故事──不是因為錯誤本身，而是因為共同創辦人 Larry Page 的回應：「我很高興您犯了這個錯誤。因為我想要經營一家，變動得太快速、並作了太多超出看似不必要的事情的公司，而不是太過謹慎而做得太少的公司...如果我們沒有犯任何的錯誤，我們就不算冒了足夠的險。」創新文化可以自然地從領導者無意識的行為中散布，但無意識的行為存在風險（因為它有可能支持或反對創新）──有些公司有意識地形塑能夠傳達關鍵價值的故事。速食店連鎖店 Noodles & Company 就創造了一個公司傳說，它邀請各地的軍樂隊伍在 100 個地點快閃演奏。在極度競爭的速食店找到找到差異化是一個艱鉅且需要持續努力的方向，但這個故事時時提醒人們需要持續的「特立獨行（march to the beat of a different drummer）」。

7. 不是標準化地複製他人的創新行為

每一家的公司文化都在本質上不同。因此當您正在培養創新，即是在培養一個獨特的系統，代表者您必須要深思熟慮您的方式。不論您作什麼，都需要配合您公司的價值和目標。而在每一個個案中，管理者都必須要讓在創新文化中扮演重要角色的人具有一個容易上手且獲益良多的方向。

本文編譯自 Fast Company 〈 6 Ways To Create A Culture Of Innovation〉。

我的一天是这样度过的

Tue, 21 Jan 2014 00:02:35 CST

大家好！我是Semih Yağcıoğlu.

我是一个程序员。我生活中土耳其首都安卡拉。我喜欢编程，挑战难题永远是让我兴奋的事情。

我会写一些我感觉有趣的东西。

这是长话短说——来和我喝一杯咖啡，我们可以细聊。

这些年来我养成了一些生活及工作上的习惯。我想这些习惯也许会对你有些启发。

早上

每天大概在6点到6点半间起床。不需要闹钟。我要求是自然醒。7点钟左右吃早餐。锻炼15到30分钟。在出门上班前，我会选出今天要完成的3个最重要的任务。

早晨是安静的。早晨我注意力最容易集中，能完成更多的任务。所以我努力在上班前尽可能的多完成几项事情。

工作

我拒绝同时做个事情。同时做多个事情会一个都做不好。我一次只做一件事。

我总是对任务划分优先级。我的座右铭是马克·吐温的一句话，“早上先活吞一只青蛙，那你余下的这一天时间将不会再遇到比这更糟糕的事情了。”

不管是工作还是业余时间，我都奉行收件箱0原则[0]。如果邮件箱里还有没有处理完的邮件，我有三种处理方式：回复，删除，或转给他人处理。最终，它们都会进入归档状态。

不管做什么，我都会尽全力专心一致。为了达到这种状态，我会在工作时关掉或清除所有的干扰因素。只有这样我才能专心的干那些真正重要的事情。

我会把任务分块，我使用番茄时间管理法，它能帮助我专注于当前的任务[2]。做事情的期间我尽量不中断，坚持一口气完成。如果你把任务分成20分钟的任务块，每20分钟不中断，你会惊奇于你的工作效率。它让我保持了工作动力，让我能头脑清醒的干活。这种一次次的小冲锋、一次完成一个任务块的方式，让我感觉工作变成了游戏。

工作中间穿插短时间的休息，这些休息时间里我做我任何想做的事情，和朋友喝咖啡，浏览 Quora， Hacker News 或者 Stack Overflow，这些都是我在休息时间最喜欢的活动。

饮食

我不喜欢一个人吃饭。我总是和朋友或同事一起吃。这是一种很好的社交方式。聊些小东西，想法，项目等，这些能让我了解外面发生的事情。这跟你的工作繁忙与否无关，毕竟大家都要吃饭。

我喜欢到外面吃，哪都行。这能让你保持新鲜感，而且有助于清理大脑。

做笔记

我使用一个方形的 Moleskine笔记本和一种黑色钢笔做笔记。我养成了bullet journal[3]的习惯。我会尽可能的记下所有有用的信息。没次当我重新翻阅以前的旧笔记时，我都会惊奇于发现一些已经忘记的好东西。

除了用纸质笔记本外，我一直还用手机或电脑本做记录。但是，如果你没有好好的组织这些笔记，它们的混乱会让你很麻烦。所以，我制订了一些规范来管理我这些笔记。手机做笔记非常方便。但有时候你也会遇到使用手机或电脑笔记本做笔记不方便的时候。比如会议中别人会以为你在聊天或发短信。所以我学会了随身带一个纸质笔记本。因为提着电脑走到哪带到哪并不方便，所以带个本子就成了习惯。特别是，我把它放在枕边。你不知道什么时候灵感会突然冒出来。

工具

我使用 Evernote来保存所有的想法。能用它的地方我尽量使用它。我把它装在所有设备上。将所有的物理东西都数字化，保持到Evernote里，会最大化的避免信息混乱。

我使用 GitHub存储我的所有项目，甚至我的写作。

我喜欢写作，我使用Web应用ZenPen写作，用的是一个有标记语言的编辑器[4]。它很简单，也很漂亮。我使用LaTeX写学术论文，也会用一些其它的看起来很酷的东西写[5]。

我用RSS阅读文章。我偶尔玩 Twitter。我从来不去Facebook。

我使用Pomodoro应用，它非常简单，其实就是一个计时器。

晚间

晚饭后我继续工作。睡觉前我会做一会儿身体锻炼，一般不超过15分钟。这能让我保持清醒，有助于工作。

睡前我会回顾一下做的笔记。包括本子上记录的和电脑里记录的。我会清理完收件箱，每个邮件都做出相应的处理。

回顾笔记后我会计划明天的事情。知道下一步该怎么做是解决掉了一个肩头的重担。

无论我如何疲劳，我都会为我自己做一个事情。读一本书，看一个电视节目，或写一些我喜欢的东西。这对我很重要，我会坚持下去。

标注

[1] Inbox zero 是指清理干净你的收件箱，消灭所有纷扰的事情。

[2] Pomodoro 是一种把工作分成25分钟左右的时间段，中间休息5到15分钟的方法。

[3] Bullet journal 如果你喜欢做笔记，这是个很好的东西。

[4] ZenPen 是一个极简主义的Web应用，是我目前发现的最好用的写作工具。它能帮助你专心写作。我使用标记语言，存到本地可以离线写作。

[5] LaTeX 对你的眼睛很好。每次我看一个文档，不论是不是打印出来的，我都能看出它是不是用LaTeX编写的。它就是这么漂亮。

感谢 Kevin McKeown启发我写这篇文章，还感谢 Evrim Doğanyiğit, Aykut Aras, 和 Mehmet Kordacı 预览这篇文章的草稿。

本文由外刊IT评论网( www.aqee.net)原创发表，文章地址：我的一天是这样度过的，[英文原文： This Is How I Work ]

你也许会喜欢这些文章：

神器valgrind

Thu, 13 Feb 2014 17:07:23 CST

其实早在2006年我就用过valgrind，但当时valgrind不能观测daemon的内存泄漏问题，所以后来渐渐用得少了。

今天又遇到一个内存泄漏问题，程序颇大，手工调试不太现实了，所以又想到了valgrind，毕竟在这7年间，valgrind又强大了不少。查了一下，它已经可以检测daemon进程了，方法在这里对应的官方文档在这里其中"monitor leak_check full reachable any"相当于设置gdb的breakpoint。

不过，我要调试的这个程序，一运行就fork了，然后子进程负责主要的逻辑，父进程只是等待子进程返回用的，而且，只在运行某个特殊逻辑时出现内存泄漏，平时的逻辑没有问题。怎么弄？折腾了一下，发现可以搞定：首先，在gdb里运行“set follow-fork-mode child”来自动跟踪子进程，然后，一开始不要急着用”monitor leak_check full reachable any"来检测，先"continue“运行一阵子，当开始跑造成内存泄漏的逻辑时，再ctrl+c打断，再”monitor leak_check full reachable any“设上断点，自然会吐出valgrind的memleak信息。

用这两招，果然找到内存泄漏的点了，隐藏颇深，如果不是用工具，真不知何年何月才能发现。感谢valgrind神器，支持vgdb支持daemon检测，真是杀手级的新特性。(我用的是最新的 valgrind-3.9.0，老的valgrind估计不支持)

另外说明一下，我是gdb的小白，以上招数和解释不见得正确或最优，如有行家肯指点，感激不尽。

为什么要加入百姓网？

Fri, 15 Nov 2013 16:54:00 CST

昨天陈宇翔来找我问我这个问题，我发现之前在百姓网还小的时候曾经思考过这个问题，无非是创业的激情，还有远大的前景，而随着我们业务的发展，外界环境的变化，发现需要重新来思考这个问题了，正好趁着这个机会来梳理一下整个的思路。我整理下来发现三大理由，我认为这三大理由更多的是展现了我们的鲜明的个性，而这鲜明的个性都有鲜明的弱点，如同《浪潮之巅》里面的公司，都是“成也萧何，败也萧何”是那个基因让他成功，也是那个基因让他失败的，所以这些个性特点，喜欢的人应该会非常喜欢，不喜欢的人必定不喜欢，而没有存在对错的概念。

1. 一个需要用智慧来改变的潜力巨大的行业

我把这个放在第一位，原因很简单，男怕入错行，女怕嫁错郎。行业选择是非常重要的事情，首先分类广告是什么，它是一个只用30人就可以实现一年1亿美元收入的行业，他对于玩转他的人的要求很高。有些人会问我58上市了，我们还有戏吗？我的问题只有一个：你相信每个家庭都会去卖二手吗？我相信会，但是他们还没有做到，他们只是把商家信息往网上搬了，而我们希望是每个个人信息也要一起上去，并且个人信息应该是更多的。做出来了吗？还没有。而现在移动互联网大潮又来了，一则用户使用会扩大10倍以上，第二会带来模式的全面革新，哪怕是craigslist这样传统的分类广告巨头，都有可能在新的情况下倒下，这是一个关系到每个人的，有无数可能性的行业。

2. 理想，专注，经历起伏的管理层

虽然可能是很好的行业，可是为什么是你们呢？你们做了那么久的时间，为什么没有做出来呢？很多人都会有这样的问题来问我们。我们曾经犯过很多创业团队都犯过的错误，但是我们还没死，并且还站起来了，所有不能致我于死地的东西都会让我更强大。每个行业都应该有一群适合这个行业的人来做，如果要求快，让慢的人做了，会死。如果要慢，让求快的人做了，一样会死。分类信息在中国到现在为止都是一个慢的过程，而且国外也是这样的情况，他起来的很慢，所以就需要做的人有耐心和专注。同时我们有时一些很有主意的人，很能自娱自乐的，一个事情做9年，还能整天翻出新花样来折腾，不让自己觉得无聊。关键是9年过去了，还是那么地执着地爱着这个事业。

3. 神一样的队友

有一句话叫：不怕神一样的对手，就怕猪一样的队友。在百姓网没有一个人是不想干活的，每个人都是用一股热情倾注在自己的工作中。要问怎么做到的？我们在面试过程中需要考核的重要一项就是内驱力，即你是为什么而干活的？是需要被别人驱赶着走的，还是自己找自己想要做的。我们还会看一个人的解决未知问题的能力，就是在你从来没有做的事情面前，是否能够闪现出思考的火花，找到最好的方法。除此之外，我们会注重每个人的特点的发挥，找到最适合他发挥才干的地方，我们不会去强迫人去改变，因为根本没有必要，我们是帮你找到最能发挥你才干的地方。我们这里有十几年的数据仓库工程师，也有ACM的全球决赛选手，也有中级焊工，也有吉他高手，好像每个人都是那么多才多艺，除了我，多才多艺和我无怨。

总结一下，在我看来，选择一个公司，我会看三点：一看行业是否有美好的未来，可以站在浪潮之巅；二看领军人物，是否有远大的理想，而又脚踏实地；三看团队，每天朝夕相处的人，是否有我学习之处，是否在一起奋斗。

坚持最初的用户体验梦想

Thu, 19 Dec 2013 16:45:02 CST

这是在UXPA十周年工作坊前期的一个采访，我的十年也过去了。一年一个Slides，总结自己的工作和心得，把一些经验和方法分享出来，是我每年给自己定的计划。在分享以下文字的同时，期待下一个十年和用户体验的未来。

刘云天，唐硕咨询用户体验设计Lead，拥有12年用户体验设计经验，曾就职于网易、腾讯。在腾讯工作期间，他是腾讯电商平台设计中心负责人，出色完成腾讯首页改版、腾讯电商等多个重点项目。加入唐硕后，他从事电商领域用户体验研究与设计，更好的服务更多企业。

记者：您的工作坊中有个“微”交互的概念，为什么要在交互前面加个“微”字？

刘云天：交互能够让不好产品的体验得到修正与改变，微交互可以让良好的产品体验得到完善与升华。一些公认比较好的产品，并非每个点都做得完美，而是在关键的核心路径上做得优异。比如iPhone，你想关闭一个App的提醒通知没那么容易。但iPhone重视的是你的核心体验，并做到了极致。我们做设计，并非一定要花大把的精力去解决那些体验较差的问题，设计更应该解决那些反复使用的，核心功能的体验问题，这是一种自下而上的方式，这就是微交互。通过在细节上一点一点的逐步改进，从而引爆整个产品的体验变化，这是微交互的价值所在。

　　我认为“微交互”无疑是一种解决问题的方式，我会在工作坊中详细介绍，通过长期经验积累形成的关于这种方式的方法论。根据这个方法论，如何规划用户体验在某个方向的点上寻求突破，这是令人期待的。

记者：请给我们着重介绍下您对电商手机端用户体验的一些观察吧，相信现在很多电商人特别关注这个。

刘云天：我们先把手机端定位在Mobile端，Mobile代表移动，手机只是一个渠道。Mobile端是一个新的平台，大家都在关注和学习。因为新的平台打破了旧的规则，带来很多不一样的东西。对于设计来讲，本质上不会发生太大的变化，还是要在小界面上致力于用户体验的提升。从UI的表现来看，Web端更偏重细节的表现，在一个小控件上能够产生大量的体验，而Mobile端不会在控件上表现太多，要轻，Mobile端更应该关注的是内容对于用户的影响。由于手机界面小、电量少、使用时间呈现碎片化，手机端的应用不可能照搬网页端的界面，而是要做到足够的轻。或许将来还会有更新的界面与交互方式，但本质上是对用户体验在形式上的演进与改善，这是没有变的。你产品的每个接触点都是一个微交互，在界面上的感受、体验好不好，能否带来商业价值，这才是根本的。这与平台本身变化并没有太大的关系。有人做PDA，后来做电脑，现在做Mobile，都同样优秀，他叫Jonathan Ive。

　　举例来说，先前做过一个的项目，上线以后收到很多投诉反馈，但在UI方面我们有自信解决80%-90%的问题。后来发现真正的障碍是在之前的流程设计，步骤太多，门槛太高，降低了用户的转化率。因此解决投诉问题的关键是想办法减少之前的不必要步骤，降低门槛。在我看来，设计师不仅要解决UI方面的问题，而是也要解决用户在使用产品中的每个关键接触点的问题，这些影响了用户的最终体验。当然问题解决的过程中还有部门架构等因素的影响，设计师也许不能完全控制决策，但还是可以使用一些方式去说服相关人员，设计师要敢于打破成规，撬动体验，优化那些老旧的决策。这是Web端上的案例，你会在Mobile一样找到类似的东西。

　　再比如电子商务中的二次购买场景，在支付流程上我们可以做很多的简化，比如默认前置购买的支付方式、收货地址等等；购买之后的分享也大有文章可作。你会发现，把产品的用户行为模型设计得足够详细，你就能够找到很多可以待优化的关键点，找到通过设计提升商业价值的机会。这个场景在Mobile端是完全一样。

　　新出现的平台不一定会在短时间完全颠覆旧的平台。即便是颠覆我认为也尚需较长的一段时间。在这之前二者可以相辅相成，做跨渠道结合。其实在传统行业如线下金融业，同样有手机端应用的体验结合点。比如一些轻量级的业务流程搬到手机上去完成，提高办理业务的效率，无缝接合线下线上的体验；再比如VTM（Video Teller Machine），利用终端远程提供人工服务，既令用户有安全感，又降低了服务成本。

　　我认为互联网的本质也是服务，只不过互联网在服务上想得更多，走在更前面、演进速度更快，更开放。而传统行业也希望把服务做好，甚至打破原来固有的一些规则。这方面的机会空间是很广阔的。而体验提升的突破点，就是前面提到的“微交互” 。

记者：从做设计到做设计咨询的职业转变，您是有怎样的考量？有何心得可以分享给一些同样达到一定经验年限正在考虑转型的设计师？

刘云天：我最早是在大学母校里面做学校网站，那时候条件很艰苦，国内也还没有交互设计或用户体验概念，我一个人什么都做，包括问卷调查、视觉设计、前端开发……当时画的线框图稿我现在还保留着，一些场景现在想起来还是很激动的。

　　后来学校里面发展空间有限，去了网易，再后来到腾讯，工作了十来年。期间经历蛮多的，包括偶然的机会下去做了一段时间的前端开发，制定了可能是腾讯最早的网站前端开发规范；像在2004年就接触到“重构”“自适应”这些相关理念，这些理念在后来才被应用开来。后来唐沐找到我说能不能做一些交互设计的工作，我就加入了当时他负责的UI设计组（后来的腾讯CDC），而那时我对用户体验的理解还仅是可用性方面的一些知识。在三四年的时间里，我负责了比较多项目的交互设计，包括2008年3月份上线的那一版腾讯首页改版，外界评价那是腾讯在那几年里做的最大变化。在项目的过程中我愈加热爱交互设计这项工作。对用户体验、交互设计的认知有了更进一步的提升，也就知道了有UXPA这样的行业组织。

　　再后来CDC要去支持公司各部门的业务，我就去到了拍拍，花了不少精力，让原本没有交互设计的部门，从只考虑商业需求，也能关注到用户体验，那个时候我是拍拍用户体验组的Teamleader。

　　我觉得设计师要去影响其他人，才能改变大家对某些事物的认知。但其中的过程是不容易的。首先他要懂很多东西，有丰富的经历，宽阔的眼界；其次要有勇气去表达、沟通，去努力改变。设计师不能私下里抱怨，那是不成熟的表现。当然，如果你成长为一个管理者，确实会在某种程度上增加说服力，那是在行政上的，不是真正的说服；但并不是说你一定要去做管理者，才能影响别人。作为设计师，你要去锻炼这种能力，如果不去有意识的增强这种能力，你会越来越紧张，越来越没信心，会渐渐失去对工作的兴趣。这里也和情商等很多都有关，但更关乎你是否坚持最初的梦想。

　　我喜欢去关注和探究用户的每个细节体验，加入唐硕，是想看看能不能把自己长期积累下来的专长带到其他领域。我相信用户体验理念和方法可以给传统行业，或非互联网行业带来更大的改变，通过设计去创造更大的用户价值与商业价值。

记者：所以这是一个寻找、坚定、传播用户体验理念的成长过程。谢谢您的真诚分享！

如何用“友好”的方式告诉经理：拥有一个好程序员是你的幸运？

Tue, 25 Feb 2014 00:31:11 CST

我有一个朋友，他在一家小公司工作，这家公司最近换了经理。老经理由于资深程序员的辞职且无法招到替补而被派去顶替空缺的开发角色。而新经理缺乏管理程序员的经验。

这位朋友最近被新经理单独谈话，是因为他每天只在办公室里待6-7个小时，上班时间喜欢外出，然而，如果是能独立完成的工作任务，他从来不拖后腿，但如果是需要和同事相互协作的任务，那就另说了。新经理要求他每天必须在办公室待够8小时，不为别的，就是因为担心他的迟到早退会让其他程序员以为也可以这样随便外出或缩短工作时间。

这位朋友相信公司里的另外一个资深程序员也被叫去了个别谈话，并被告诫了相同的事情。让我这位朋友担心的事是，这位资深程序员的脾气可不是那么好，一旦他一拍屁股走人，那整个公司业务都无法继续下去了。

事实上，他们公司的任何一个资深程序员都可以随时拍屁股走人，而且在一个星期里就能找到一个比现在高出30-40%工资的新工作。他们大部分都是因为宽松的环境和能将个人时间加塞到工作时间里才留在那里的。

这位朋友很苦恼，他想让经理知道，他并不是一个异类，他们几个程序员都是这样，最重要的，他们是按时按计划编写出高质量的软件的。他感觉这事很棘手，如何才能表达出这个意思，而且不带出任何的指教或威胁的意思。

我很体谅这位朋友的苦恼，我想，如果他不是在这样的一个小公司，而是在谷歌或Facebook这样比较开明的公司里，那他不会有任何的问题，会工作生活的都很开心。鉴于他目前的处境，我是这样回复给他的：

你的经理的工作就是管理你们。而你是想去告诉他如果他这样坚持下去你就会辞职。不管怎么做，这必将发展成一次充满敌意的讨论。如果你想说明你的意图而不显露出最后通牒的架势，首先你需要理解他的动因，然后才和缓的说出你的。不管他怎么说，尊敬他作为领导的权威，和气的开始，礼貌的结束。

理解他的想法

“公正的站在别人的立场上看事情。”

- 戴尔·卡耐基，《人性的弱点》

你认为这位新经理只关心8小时时间的长度，认为他以前没有任何跟程序员打交道的经历。但你确定吗？老经理被调走，可能是因为他没能加强制度管理。也许是上级领导注意到员工经常的上班时间不在办公室，要求新经理改进这种现状。也许他正担心他的位置也做不了多久，因为公司的精英程序员在流失。

上面的每种情况从他的角度来说都是非常不同的问题，需要你这边考虑不同对策来应对。与其直面冲突、把话说死，不如先去问问他的这些管理措施的动机是什么。比如：

你好，老板，我想跟你谈谈关于我们的上班工作时间问题。自从加入公司，我们都非常喜欢这种自由的工作时间安排。公司也鼓励这种在保证完成任务前提下的工作-生活之间的健康平衡。因为以后我们要长期共处，我很希望理解你的这种管理方式的初衷。能否向我们解释一下你为什么要做这些管理方式上改变？

关键是要表达出， “我感觉这种变化有点突然，一时适应不了，作为一个成年人，我希望知道你的想法。”，而不是去跟他争论。留给他思考的机会，让他解释，也许从他嘴里说出来的好理由会让你震惊。

温和的说出你的观点

“不要批评、谴责或抱怨。”

- 戴尔·卡耐基，《人性的弱点》

也许你会不同意他的理由。也许你会想这太愚蠢了，会将所有人都赶出公司。而且确实有可能会出现这种结果。但是，直接告诉他这些不会起到任何作用，只能让他恼怒。你需要温和的表达出你的立场，例如：

之所以我会在这里这样兢兢业业，部分的原因就是公司提供了我一个灵活的工作环境。我知道，你希望我待在公司里8小时是因为 XXX理由，能否我们找到一种方式，即可以满足你的需求，也能让我继续保留一定的灵活性，让我在上班时间里自由的做一些其它事情？

通过表现出一种寻求折中方案的姿态，请求他引导你找到问题的答案，相信他会很愿意给你一些缓冲的空间，这比在不考虑他的情况下直接要求他要好的多。

尊敬他的权威

不管怎样，他是经理，是由他来做决定的——不管你是否同意他的做法。尊重他的决定。

如果他最终妥协，同意你拥有一定的自由度，那就说，“ 非常感谢，很高兴在你的领导下工作。”

如果他完全不接受你的劝告，要求你必须每天8小时，有事必须请假，那就说， “非常感谢，很期待能和你共事。”

发最后通牒不会改变他的想法。如果你真的无法忍受在他的领导下工作，那就去找份新的工作吧，把辞职信交给他。威胁辞职的做法影响你的工作，影响你的心情(甚至更糟)，所以，友善的说再见才是正确的行为。与其一副吵架的样子，不如用将心比心的姿态更能产生想要的结果。

本文由外刊IT评论网( www.vaikan.com)原创发表，文章地址：如何用“友好”的方式告诉经理：拥有一个好程序员是你的幸运？，[英文原文： What is a 'friendly' way to let managers know that having good developers is a privilege? ]

你也许会喜欢这些文章：

哈佛经济学家关于工作效率的意外发现

Wed, 28 Aug 2013 00:13:57 CST

职业人士最常见的一种抱怨是：时间太少。

每周工作超过60小时的人会抱怨甚至挤不出时间来处理他们邮箱里的邮件，更别说有创见性处理大项目中的问题。

但时间并不是问题，哈佛经济学家 Sendhil Mullainathan说。最终阻碍你成功的是你的大脑“带宽”使用效率，或集中精力的能力。

Mullainathan的研究主要针对是资源稀缺情况，当人们缺少某些东西时会如何应对——可以是缺钱，食物或时间。他和他的搭档普林斯顿大学的心理学家 Eldar Shafir在周二的每年一度的Aspen Ideas节上公布了他们的发现。

他们发现，这些资源短缺导致人们不能作出正确的决策。因为他们的大脑只能够处理这么多事情。

这种问题会发生在各种人身上。忙碌的职业人士无法有效的规划他们的时间，同样，低收入人也无法正确的处理他们的贷款计划。他们被分心了，Shafir说。

从你自己的生活中选取一个例子：如果你渴了，非常想喝水，你很难再思考其它事情。如果你缺钱，债务相关的问题会时不时出现在你脑海里。

工作中是同样的道理。缺少时间不是问题；问题是缺少专注。

Mullainathan的关于工作效率的顿悟来自于他的一次把手机遗忘在厕所里的经历。

那天晚上，他出去和朋友一起吃饭，他发现玩的特别开心。并不是他的那些朋友变得更有趣了。也不是食物比平时更好。唯一不同的是他没有带手机。

因为如此，在饭前或饭中他没有收到任何讨厌的邮件通知和短信。“这两个小时里我的大脑带宽只服务于我想专注的事情上，”他说。

从此后，他做了其他一些习惯的改变。他不再用手机来接收邮件。在会议前，不再去检查邮件，这样他能专注于讨论。

他最终明白了其中的道理。

“以前我认为充分使用了每一分钟——‘嗨，还有5分钟，我可以检查一下邮件’——这实际上是错误的使用了大脑带宽”。

Mullainathan最后让观众回想一下福特汽车创始人Henry Ford的一个往事。

这位汽车制造商在1900年代早期创造了一个著名的发现，他想通过让工人的工作时间增加到每周60小时来从他们身上榨取更多是生产价值。但是，这样做了之后，生产力的增加只持续了4周时间。之后，工人们每周60小时的生产力还不及进行对比的每周只工作40小时的工人。

超时工作的人缺乏的“不是努力工作的能力，而是真正用心思考问题的能力”，Mullainathan说。

对忙碌的人的教训：时间不足不要紧。高质量的使用现有的时间。

本文由外刊IT评论网( www.aqee.net)原创发表，文章地址：哈佛经济学家关于工作效率的意外发现，[英文原文： A Harvard Economist's Surprisingly Simple Productivity Secret ]

IT瘾工作推荐

极简 Java 工作流概念入门

1. 为什么需要工作流

2. 三大工作流

3. 流程图

SRE 的工作介绍

Infrastructure

Platform SRE

业务 SRE

部署服务

Oncall

制定和交付 SLI/SLO

故障复盘

容量规划

用户支持

相关文章:

URL Disabler 1.0 免安裝版 - 禁止瀏覽指定網站

分享：个人是怎么学习新知识的

一、早期

1.1 入门：找教学视频

1.2 实战：模拟项目

二、15年后

2.1 入门：GitHub Demo

2.2 系统学习：官方文档

2.3 实战：模拟项目

2.4 深入：带着问题分析源码

2.5 广度：跟进业界动态

三、16年后

3.1 写博客：让别人也能懂

四、写在最后

实用技巧：教你如何在没有网络的Linux机器上快速安装软件

最土但最极客的方法

不那么土也不那么极客的方法

个人最喜欢也最简单的方法

其他方法

拓展阅读

分享我司基于K8s & Spring Cloud的私有云技术选型！

平台级

监控

代码质量与管理

svn 钩子开启

从Excel到微服务

微服务与架构师

创业公司需要基础架构团队吗？[极牛编辑修改版]

每日站会、代码审查、结对编程 之开源中国实践

雪球在股市风暴下的高可用架构改造分享

【干货】大众点评运维架构的图文详解

分享内容

1、点评运维团队的配置

2、点评的整体架构

3、点评运维系统介绍

3.1 全方位监控系统

3.2 自动化工作系统

3.3 配置和管理系统

3.4 记录和分析系统

4、运维踩过的坑和改进的地方

5、未来关注的领域和方向

结束语

创业未必给职业生涯加分

长期通过微博、微信、知乎等平台接收碎片化的知识有什么弊端？

1、碎片信息通常具备这样的特征：

2、这样的结果是：

3、具体的方式是：

4、再多谈几点

5、Refer：

在互联网时代如何工作得更简单

1、特定时间处理特定信息

2、把信息聚合到一起

3、和团队共享信息

写在最后

为什么有些人用一年时间获得了你十年的工作经验？

技术合伙人的故事

目前腾讯哪个部门最值得加入？为什么？

MYSQL数据库常用知识整理

科技创业公司的效率工具箱

Defonic for Relax

Tips: Defonic 默认情况下是不显示背景的高清大图的，你需要点击右上的HD小按钮才会出现如此的身临其境的图片。

痛并快乐着

相关文章

要想提高工作效率，请拒绝做这7种事

每日站会、代码审查、结对编程之开源中国实践