What

By using docker , we can easy deploy the application. but how we control the deploy version and how can we rollback to last version if any error occur?

There is the solution we explore in development.

How

To control which version docker image need to deploy to prod. we need to defined the target ‘sign’ for our docker image, something like: “master”, “prod”.

To rollback to the image we want. all image need to have a ‘sign’ for rollback , something like: “2021-01-01 10:00:00 - asdffe”, “release date + commit id”.

so we need to push two image to docker repo: master image and release date + commit id image.

master image will overwrite old image all the time. the release date + commit id image will be saved in repo for rollback

Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
TAG = date + commit id

REGISTRY=your registry

NAME=image name

PROD_TAG = master

UAT_TAG = uat


## build prod

# build image

docker build -t ${REGISTRY}/${NAME}:${TAG} .

# create image with PROD_TAG` `for` `PROD RELEASE

docker tag ${REGISTRY}/${NAME}:${TAG} ${REGISTRY}/${NAME}:${PROD_TAG}

docker push ${REGISTRY}/${NAME}:${TAG} && docker push ${REGISTRY}/${NAME}:${PROD_TAG}

## build UAT

docker build -t ${REGISTRY}/${NAME}:${TAG} .

docker tag ${REGISTRY}/${NAME}:${TAG} ${REGISTRY}/${NAME}:${UAT_TAG}

docker push ${REGISTRY}/${NAME}:${TAG} && docker push ${REGISTRY}/${NAME}:${UAT_TAG}

Problem we meet

  • teambuild效果不明显
  • teambuild活动目的不清晰,teambuild活动到底是想达到什么效果?
  • 团队成员参与度不足, 被动参加,置身事外
  • teambuild形式单一,没有创新(一般都是吃饭)

For What

为了解决上面的问题, 通过轮流举办teambuild的形式,加强团队凝聚力,提高团队成员参与度, 构建积极参与的团队文化氛围。

Whom

团队所有成员,每次的团建活动按照姓名排序,轮流三个人进行teambuild活动组织安排。通过轮流的形式,提高团队成员对teambuild的参与度,引入更多思考变量。

举例:
Alex, Adam,Benjamin, Freddie,Remox,Sura

如上面的,第一季度由Alex, Adam,Benjamin进行teambuild活动组织安排。第二季度由Freddie,Remox,Sura组织安排

When

每个季度最后一个月进行teambuild活动
1-3 3月
4-6 6月
7-9 9月
10-12 12月

需要在每季度的第二个月发出活动计划,进行计划的投票,人员的安排。
1-3 2月
4-6 5月
7-9 8月
10-12 11月

How

计划

首先,不同的teambuild活动,要达到的目的可以是不一样的。
例如:

  • 前一阵子团队全部人员加班加点帮忙赶计划, 所以想让大家能够比较好的休息,放松一下。 所以安排了放松的teambuild: 温泉, 按摩 等
  • 发现大家之间除了日常工作,没有其他交流, 所以安排了团队交流,协作相关的活动:对抗赛,CS,王者荣耀线上比赛。

  • 疫情期间,大家运动不足,交流也比较少,所以安排了能让大家进行运动,又可以促进大家交流的活动: 每日步数比赛。

所以针对不同时期,不同团队的teambuild,需要每个季度轮到的同学,首先考虑一下,这个teambuild要达到的目的。再根据目的进行计划。

计划落实

确定了大概的计划,需要去了解对应的信息,价格,人数限制,时间限制,天气。
建议是至少包含两个计划,
计划一是可以用公司teambuild基金覆盖的,基础的活动。 计划二是更上一层的,需要大家再加点钱的。

和团队其他成员沟通,投票,确认要进行哪个teambuild活动。 确认人数。 确定teambuild时间

活动进行时

  1. 确保 提前和所有成员分享了活动注意事项: 时间,地点,安全事项 等等。
  2. 携带对应的安全保障设备,如:药箱
  3. 确保所有人员都平安归来
  4. 其他…

绩效评估的作用

绩效是衡量一个人或团队的工作效果的指标,通过绩效可以清晰比较到公司各个人员的情况,再根据绩效进行相应的处理,奖励或者鼓励或者惩罚。如果没有绩效,公司将失去活力,没有发展。

评估绩效的几种方式

基于360度的综合考核

360度综合考核,多视角考核,考核者被上级,下级,同级,合作者,外部考核者(供应商和客户等)等 匿名 进行考核。
考核一般使用调查问卷形式,市面上有提供360度绩效考核问卷的公司。
考核者的多角化,有助于 考核 被考核者在不同的合作关系中的表现。 显示出隐藏的问题。
也对鼓励考核者进行多元化,全方位发展有所帮助。

建议:中高层绩效管理

缺点:

耗费人力,时间较多。

侧重综合考核,定量考核较少,定性考核较多。
例如考核 您觉得和被考核者一起合作,满意度多少?1-10分。 这种比较定性的,不是定量的考核,存在一定的主观判断。

因部门的岗位数量,岗位性质不同,会产生一定不公平。
如技术部门和商务部门,同样考核第三方对他的一个沟通流畅程度。可能技术部门或有所欠缺。需要再根据部门进行对比。

基于KPI,OKR的绩效考核

KPI:关键绩效指标
OKR:目标与关键成功法
通过KPI,OKR指标进行考核,考核内容明确,有利于被考核者与公司形成共识,容易被接受。

建议:低中高层绩效管理

缺点

有可能导致机械化的考核。
如 完成KPI指标就完成了绩效。其他不管了。没有考虑其他的人为因素,弹性因素(如家人生病,导致无法完成)。

基于BSC的绩效考核

BSC:Balanced Score Card, 平衡计分卡,通过对 财务(Financial)、客户(Customer)、内部运营(Internal Business Processes)、学习与成长(Learning and Growth)四个方面进行考核评估,得出绩效。

建议:中高层绩效管理

基于目标的绩效考核

通过制定目标,通过目标是否达成来衡量绩效。

缺点:目标的制订存在异议,怎样的目标才是符合考核的?
与基于KPI的绩效考核类似,容易忽略其他因素

建议:低中高层绩效管理

绩效积分奖励制

绩效积分奖励制, 对员工绩效实行积分,绩效积分形成“福利购买力”,在购买力达到一定水平后,员工可以凭借获得的购买力获取企业提供的弹性福利。

建议: 低层绩效管理

适合企业的就是最好的,没有完美的方式,需要在企业管理制度的基础上,进行评估使用哪种绩效制度

团队OKR

Object:目标
Key Result: 关键结果

OKR的目标是引导,驱动团队成员主动的去思考, 主动的想怎样能达到对应的目标(Object)。 OKR需要团队成员参与制定,并了解每一项内容(Key Result)。

每个团队都有自身的特点, okr需要根据不同的团队,不同特点进行设定。

Object 目标,定性,定义事件的性质,不要定义数量,抽象化:如“赚到1亿”, 而是使用 “公司盈利,上市”。

Key Result 关键结果,定量,定义需要达到多少,如“赚一个亿”

ORK 必须是公开透明的,由上到下, 公司的OKR,团队的OKR, 个人的OKR

可以参考的制定规则

普遍的OKR示例

提高发布频率

每周发布一次

所有的发布都应该分割成较小的部分, 能够进行zero down time的部署, 不影响到生产环境使用(数据库修改除外)

参与发布的人数达到全员

团队所有成员都熟悉整个发布流程与工具,没有知识断层

提交代码到版本管理服务的人数达到全员

所有开发人员都必须提交能够使用代码版本管理服务,提交代码到版本管理服务

15分钟完成所有发布工作

完善发布工具, 减少发布时间,单个服务发布时间不能多于15分钟

其他能提高发布效率的举措

减少生产问题

减少生产问题数量 由10减少到5

生产环境的问题应当逐渐减少, 直至没有

生产问题影响

生产问题的影响,应该能够衡量, 并且影响逐步减小

生产问题处理人员数量 由1加到4

生产问题人员处理数量应当在合适的数量, 逐渐减少,建立良好的问题处理模型

减少 新的功能导致的生产问题,由10减少到5

新的功能导致的生产问题应当逐渐减少,如: 完善对应的测试, 自动化测试, 减少问题出现。

其他能够避免生产问题发生的举措

团队建设

团队成员每月学习目标
团队分享每周有一次
证书数量每人获取到一张新证书

提高工作效能

每月举行一次团队反馈会议

团队进行会议,评估自身团队: 好的,能够提升的,保持的,需要改变的。 稳定会议数量, 固定每月进行会议。

每次一篇团队知识文章

团队发布知识文章, 分享自己的知识给社区, 逐步提高数量

减少安全问题

代码扫描工具

所有的服务都必须使用代码扫描工具(sonar, checkmark)

减少 代码扫描问题,重大问题数量为0

扫描不能出现 紧急 的问题, 逐步减少代码扫描工具扫出来的问题


上市

总流水达到5000w
用户规模达到1000w
用户日活达到100w

OKR 统一评判标准

可以看到上面的Oeject 目标都是定性的,KeyResult 关键结果都是定量的。为了更好的对比各个团队的OKR完成情况。还需要一个统一的评判标准。

一个可以看到自动采集各个团队的数据情况, 并展示报表的内部系统。各个团队可以在系统看到其他团队完成情况,进行对比。

技术架构师

  1. 构建了新项目的 前后端,自动化测试 框架(后端使用spring boot,前端使用React, 自动化测试使用 Selenide+TestNg),目前项目已经上线正常运行。
  2. 制定了项目前后端的编程规范与开发流程.
  3. 制定了团队的git工作流.
  4. 对新技术进行研究并落地(PostgreSql,Cypress,React Hook).
  5. 对团队成员进行培训(git工作流培训,单元测试培训,React前端培训,自动化测试培训 等等).
  6. 指导团队进行代码架构设计,数据库设计。
  7. 参与并构建了项目的Devops基础设施,如 自动化部署,自动化测试,监控报警 系统

Leader

  1. 以 敏捷开发 为指导, 对项目成员进行对应的思想指导。
  2. 进行 项目人员 面试,构建了一套完整的面试流程,并积极培训其他成员进行面试
  3. 日常与团队成员进行沟通, review, 建立了有效的沟通反馈渠道。

2020年是硕果累累的一年, 取得了很多成绩,在新的一年需要更加努力,争取新的成就。

安全

使用双重RSA密钥验证,平台双方都有对应的密钥对, 将私钥发给对方, 发送方 对请求体按照字母顺序排序成字符串,AES进行字符串加密, 使用私钥进行签名, 接收方 使用公钥进行签名校验。 校验通过后再进行对应处理。

统一的请求,返回格式

所有的API接口都必须 返回相同的数据格式,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{

code:``200``,` `// 非200代码 为 错误码

data: {

users: [],

user: {}

}

msg:"" // 当非200代码时, 提示错误信息

}

幂等(可重入)

API接口相同的请求体, 不同时间请求多次, 返回的数据应该一致, 如: 入件接口,返回入件成功, 入件失败, 不会从失败变成成功。

文档

可读性, 历史可追溯, 推荐使用石墨文档markdown进行文档生成, markdown文件使用git进行版本管理。

现状

各个工作人员,固定岗位,每天都重复相同的工作(自动化测试, 开发,运维处理),员工感到前路受限, 无法接触到新的东西,环境僵持,间接导致工作效率降低。 希望能进行流动轮岗。

轮岗制度优点

提高了组织的活力,避免造成单点。

员工有接触不同工作的机会,可以学习到更多的东西,间接提高工作效率。

轮岗制度缺点

轮岗会造成一定效率的降低, 熟练工替换到非熟练工,导致工作效率降低。

轮岗人员

所有在职开发人员

轮岗时间

一年进行轮岗一次, 提前一个月对新岗位工作进行熟悉,旧岗位工作进行交接。

轮岗工作

需明确各个岗位工作内容, 方便进行转岗安排。

提前一个月,对旧岗位进行工作交接, 对接替的同事进行培训, 确保工作效率不会明显下降。

For What

通过对 每周一个技术问题 进行分享讨论的形式, 营造 分享,共同学习 的技术氛围, 提高团队凝聚力,提高团队成员的知识水平。

Whom

团队所有成员

When

每周星期四 下午四点到四点半(16:00 - 16:30 Tue)

How

主持人 按照团队成员 姓名排序轮流 进行会议主持。 下周会议主持人 要在星期五(会议后下一天)准备好下周的问题

主题必须以问题的形式提出。尽量问实际的问题,不要太空泛。

问题范围: Java(spring,多线程,Jvm), Linux, 数据库, Vue,React, 算法。

尽量从简单的问题开始, 大家提问题不要问需要 深入了解后才能回答 的问题。

问题范例:

1
2
3
4
Spring中事务什么情况会失效, 为什么会失效?
数据库索引什么情况会失效,为什么会失效?
Spring中为什么要有IOC,它解决了什么问题?
为什么阿里不建议使用Executors创建线程池?

为什么要以问题的形式发起sharing?

想通过发出问题 提前带动大家的思考, 因为提出是问题, 所以会自然而然去思考,“为什么的?为什么要这样的”。

如果只是陈述,”Springboot中事务的使用”, 可能就,“哦, 会讲这个。” 大家就被动的接受, 而没有进行自己的思考。

这个也是敏捷的一part,“如何让团队主动思考”。

英文自我介绍

面试者简单的自我介绍,可以根据面试者介绍再问些问题。

(Could you tell me more detail about your last job? Do you have confidence to handle the hangwriting and listening of English?一篇全英文文档,不借助翻译 能读懂多少? )

技术相关

重点 springboot, 数据库相关。 尽量考察到实际要怎么做, 而不是问理论上的, 很多培训出来的, 理论背得很好

。 具体一些的实操相关的问题。

(springboot 事务如何使用。如何 写一个过滤器 统计Service层方法执行时间, springboot 如何统一返回数据格式。 springboot 如何写一个拦截器, 如何统一处理异常)

项目流程相关

git,git工作流, 项目管理软件(jira,禅道), 敏捷开发,单元测试, 项目监控报警。

总结

所有的问题事实上背后都对应了考察的点:

英语能力,创业心, 自我学习能力, 技术(java基础,springboot框架, 数据库),开发流程熟悉度(git工作流,项目管理软件,敏捷开发)

每一个点对应要问什么问题才能考察到,需要面试官自行总结。

面试官需要通过面试问题掌握面试者能力,不要出现面试后还在疑惑.

1
他有一些答得比较模糊, 不知道他是不是真的行!

如果觉得没办法通过这个问题掌握他的水平, 就再多问一下! 不要等到会议结束后,都无法确认候选人是否合适*

0-3 : just know about the skill, but never used (了解这项技术,但从未使用, 按了解程度评分)

4-7: has been used the skill , but just know how to use, but don’t know the Infrastructure (使用过这项技术,但不了解底层原理, 按使用熟练度评分)

8-10: can be good use the entire skill and know about the Infrastructure (能很好的使用这项技术, 熟悉底层原理,按底层原理熟悉度评分)

Skill\Name Alex
English 6
Java Base
Spring Boot
Spring Cloud
React
Vue
Python
Node JS
C#
Golang