技术人员如何做好职级晋升答辩

2019-03-27

三月即将过去四月份即将到来，很多公司年后的职级晋升安排即将结束。

同时，晋升的结果也将陆陆续续公布出来。几家欢喜几家愁，晋升成功的同事自然值得祝贺，没有过的同事也不要气馁再接再励。

对于技术人员而言，普遍有个很共通的现象，就是往往过于深入技术，忽略了平时对于沟通等所谓「软性素质」的培养和意识，造成可能无法表现出自己真正能力。下面，说说我对职级晋升的一些认知以及经验。

准备阶段

内容控制

通常来说，职级晋升是对去年整年的总结以及回顾，因此从时间的角度上考虑，答辩的内容应该尽量控制在这一年的区间范围内。当然，如果有项目的时间跨度比较长的，应该说明原因同时更需要说明自我在此项目中起到的作用。

往往，主管也答辩人都会犯一个错误，就是将「认为很厉害」的内容和技术点作为答辩的内容，这往往是有偏差的。答辩的内容选题应该从目标职级的角度出发，从目标职级考虑选送的答辩内容是否适合这个职位。

同时，需要根据答辩的时间（自述通常不会超过半小时）来确定选题的数量。因此，答辩的选题是非常重要的，往往选题错误就造成答辩方向的错误。

PPT 是门面

从 PPT 设计的角度上说，技术人员在这块的问题很有典型性，就是往往会将大段的代码（或者截图）贴到 PPT 上。

这会让评委对于内容方面会造成一定的困扰：首先，答辩过程中评委不可能对这块代码进行 Review；其次，从摘抄的这段代码来说也不能体现答辩者应有的水平。

所以，正确的做法应该是觉得需要感觉贴代码解释的地方，尽量贴流程图或者架构图或者 UML，如果还是感觉说不清楚那么建议考虑要不要简化和突出这块想要表述的内容。

技术人员的 PPT 还有个问题就是有太多的文字，这往往会造成表意不清晰。所以，个人的经验就是如果这个 PPT 超过了 200 个字，那么就应该考虑精简。

对 PPT 设计方面的技巧在这块不铺开讲述，网络上已经有更翔实的内容可以找到。

思路和角度很重要

同样的事情，去使用不同的角度去表述，往往返回的结果是不一样的。对于技术人员而言，很容易犯的错误就是将事物「描述得平淡无奇」。这让评委在答辩过程中感觉不到你在这个项目中起到的作用，以及你对这块事物的理解。

例如，有做业务的同学描述了很多对于整个系统的业务以及架构方面的设计，甚至业务的流程是如何流转。但是，根据评委的判断这是团队行为和输出，在答辩的描述中没有体现出其个人对于这个业务的思考和沉淀，以及起到的作用的影响。

所以，对于做业务的同学往往会觉得可能在技术的角度来看，光技术会觉得不够深入。但，换个角度考虑如果结合你对业务的理解，并融合到技术中输出技术的解决方案，那么高度就会不一样。

排练、排练、再排练

答辩的过程和时间是很紧凑的，因此在正式开始答辩前，进行自我排练是非常有必要的。如果条件允许，建议答辩人的主管都能把关一轮，往往在排练过程中就会发现各种问题：答辩人讲述 PPT 的时间、语速以及表达方式能力，等等。

答辩过程中

情绪控制

紧张的情绪能够毁掉所有，甚至让你说话都不利索，尤其作为「相对内向」的技术人员，这块是相对普遍存在的。因此，在答辩开始之前就应该控制和放松自己的情绪，不要过于紧张。

如果过于紧张，这里有个 Tips 可以考虑下：就是作为答辩人你可以认为这是一场技术交流，你尝试说明自己所做的工作以及出彩的地方，让对方觉得自己「很厉害」。

从评委侧也应该给予正向引导，例如答辩人进场的时候打个招呼寒暄一下，也会起到比较好的效果。

节奏控制

答辩开始需要自我介绍，建议两三句话讲重点，千万不要拖泥带水同时夹带不必要的信息。一个失败的自我介绍可能就会毁了整个答辩，毕竟这是你给评委的第一印象。

像上面说的，如果觉得很紧张，那么自我介绍的时候可以稍微刻意放慢下语速，可能会起到调节的作用。

从自我介绍转入到正题的转场口白要自然，如果控制不好演讲的技巧（也不知道应该说什么），那么万精油的一句「下面，我开始我的工作内容介绍」。

在表述 PPT 过程中语速尽量使用中速，前面说的如果排练过那根据内容以及语速，就能找到很好的平衡点。

其实还有个技巧，如果某个技术点很深入或者需要探讨，可以将这个点当作个包袱先抖出来，留给评委后面提问的时候解答。

评委的意图

需要意识到的一个点就是，评委问的所有的问题都有其含义的。如果你的回答让他抓不到他想要的点，那么你的得分会不一定很高的。

例如，当评委问你「这个系统设计的时候，你当时考虑了哪些方面」？这个问题其实反映出两个点：其一，就是你刚才答辩描述的时候没有讲透彻，或者说深度还不够；其二，评委需要个抓手需要了解你对这块的个人理解。

所以，当你回答这个问题的时候，无论从什么角度出发，千万千万不要再介绍业务和系统本身的内容了！应该从自己对这个系统的理解和沉淀出发去阐述自己的理解，如果能表达有一定的输出以及对同事和团队的影响就更好。

答辩后

关注结果、Review 自己

评委对于答辩者的评价是主观的，但是相对答辩的过程其实是客观的。这话说起来可能会有点矛盾，但从「师以质疑，友以折疑」的角度出发，评委的评价是需要去深入理解的。

对于个人而言，晋升答辩是对过去工作的总结和评价，而不是代表对于未来工作的期待和展望。无论是自我表达的原因，也可能是评委理解不同的原因，评委对答辩者的评价都是不同的，这块需要个人辩证得去理解。

换个角度上考虑，如果你当晋升答辩是一场面试，那么这将是很好理解的一场过程了，而且这场面试的还能看到「面试官」对于自己的评价，何乐而不为呢？

资源和环境

当我们上升个高度去考虑职级晋升的时候，往往就不可避免得聊到职业规划和发展这个老生常谈的问题。

无论答辩的结果怎么样，我们更应该考虑以后的发展。首先，考虑的是个人对于自我提升这块，满足了自我的期望和要求没有；然后，再考虑公司能够提供的环境，能否有个上升的正向上升空间？

能够回答这两个问题，那么自然而然，对于职级这块的理解和态度也就是水到渠成的事情了。

-- eof --

基于「树莓派」的家庭网络服务

2019-03-11

当初组建家庭网络的时候，就考虑到自己的需求：主要是网络存储、以及跑部分比较耗时的「定时任务」，例如爬虫和下载还有部分的数据处理等。

本来考虑部署一台性能相对比较好的服务器去处理，但这样子考虑到部署太过中心化不好管理，同时硬件的成本有些高而且占地的面积太大，因此就暂时被我搁置了。

后来想到空帷的朋友圈，使用「树莓派」这个方案相对比较轻量，同时多出来的「树莓派」还可以用来它用，因此考虑使用「树莓派」搭建自己的家庭网络服务。

下面是简单的网络拓扑图，同时主要说明下图中的内容：

网络拓扑图

其实一开始组网的时候就使用了软路由的方案，所以路由器的性能并不差，但由于网络基础的缘故，还是不想过多的在上面部署太多的服务；
使用了 USB 协议的的 RAID 磁盘阵列柜，没有使用 NAS 的原因是当数据恢复的时候可以当作普通的 USB 外接硬盘来恢复、简单便捷；
RAID 阵列柜和一个树莓派链接，上面跑了 Netatalk、Samba 以及 Syncthing 等文件服务，速度肯定没有 SATA 协议的快，但是家庭网络中 USB 速度不是瓶颈；
将下载、数据等应用服务分别使用了其他的树莓派去部署，平时如果不用直接插拔硬件即可；
装修的时候就单独开了一条电路用于 UPS 不间断电源使用，因此树莓派以及无线网络放大器可以不用放在同一个地方；
目前，将负责文件管理的树莓派同时用于管理 UPS 等，只要家中电源中断或者电压不稳，发送局域网广播通知应用应用服务下线，并切断 USB 阵列柜的电源；
考虑加树莓派链接电视，部署视频点播等功能，淘汰目前的小米盒子（爱奇艺在盒子上还需要重复收费，这块的费用不低）。

顺便说下，基于「树莓派」我已经写好了几个 Docker 的镜像，主要是文件管理（Netatalk、Syncthing 等）。可以直接拿来部署使用，不用重复造轮子啦：

- 未完待续 -

扩展 Helidon 的健康检查模块

2019-02-25

Helidon Logo

Helidon 是 Oracle 提供的轻量级的微服务框架，提供了 Router、Microprofile、Security 等必要的组件。相对 Spring Boot 等老牌框架而言，它的优势在于轻量同时源代码简单适合阅读。

由于是新出的框架，所以它的文档还不够完善，有时间需要阅读其代码才能明白具体的使用方式。例如，Helidon 的健康检查这块的文档就写得非常的简单，如果想要扩展按照文档中的例子代码将会写得很混乱。

HealthSupport health = HealthSuport.builder()
    .add(() -> HealthCheckResponse.named("exampleHealthCheck")
                 .up()
                 .withData("time", System.currentTimeMillis())
                 .build())                          
    .build();

实际上，Helidon 的 HealthChecks.healthChecks() 已经提供了三个默认的健康检查的反馈，分别是死锁、磁盘以及内存的状态：

/**
    * Built-in health checks.
    *
    * @return built-in health checks to be configured with {@link io.helidon.health.HealthSupport}
    * @see io.helidon.health.HealthSupport.Builder#add(org.eclipse.microprofile.health.HealthCheck...)
    */
public static HealthCheck[] healthChecks() {
    return new HealthCheck[] {
            deadlockCheck(),
            diskSpaceCheck(),
            heapMemoryCheck()
    };
}

分别看其代码就可以发现，这三个直接调用的方法其实就是 HealthCheck 接口的实现。因此，我们自己也可以按照 Helidon 的方式来实现自定义健康检查的项目，满足本地的具体业务的情况。

例如，下面实现了个显示本地服务器时间以及虚拟机的 UPTIME 的状态：

@Health
@ApplicationScoped
public class LocalTimeCheck implements HealthCheck {

  @Override
  public HealthCheckResponse call() {
    return HealthCheckResponse.named("localtime")
        .withData("upTime", ManagementFactory.getRuntimeMXBean().getUptime())
        .withData("currentTime", System.currentTimeMillis())
        .build();
  }
}

然后，在注册到对应的 HealthSupport 中即可：

HealthSupport health = HealthSupport.builder()
    .add(new LocalTimeCheck())
    .build();

顺便说一句，需要注意下：HealthSupport.add() 里面的回调都是同步执行的。

HealthSupport 默认绑定的路由为 /health，如果需要更改这块则根据源代码的提示，增加 .webContext() 这个方法即可，或者直接将其配置到配置文件中：

HealthSupport health = HealthSupport.builder()
    .webContext("/your-health-check-path")
    // ...

- eof -

無標題文檔