logo

分享用“k8s”的方式组织跨地区远程协作

头像
NaNa
129阅读12评论1 个月前

Inspired from https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
Service discovery and load balancing
每一个远程工作的个体(一下称员工),本质上是在提供服务。服务的发现即发现能够提供服务的个体。
负载均衡,即给每个个体分配合理的工作量。

Storage orchestration
根据可行的方式支付,不限制支付形式。

Automated rollouts and rollbacks
根据工作计划,完成任务即可撤离,或切换到其他任务。
如果任务不能按时完成,则可能考虑换人重新开始。

Automatic bin packing
雇主给员工分配合理的资源,员工决定怎么使用资源完成任务。

Self-healing
当不再适合工作时,替换员工,仅在员工具备工作条件为雇主服务。

Secret and configuration management
及时更新保密协议和隐私信息,且不透漏给第三方。

————update————
构成一个k8s团队的组件

主要针对控制平面组件做拆解

kube-apiserver
项目经理/team leader
需要和团队中提供服务的个体建立联系,分派任务和资源,并考虑平衡。
可以是“集群”也可以是“单例”

etcd
财务,通过工具或平台记录团队运行状况。
根据每一个个体的产出,针对异地的工作者发放薪水。

kube-scheduler
进度跟进及控制者,product owner/产品

kube-controller-manager
人事,及时跟进人员的工作状态(请假/离职)
为新成员提供boarding,账户权限etc

cloud-controller-manager
法务/人事,根据当地法律法规,制定工作合同等法律文件,确保不同地区的成员能够顺利工作,没有税法等法律风险。

其他的锦上添花的部分就不展开了

结论:
搭建这样的团队并不容易,如果是初期小团队尝试这种方式很可能要一人分饰多角。

分享主题:
其它
城市:
其他
加载中…
精选评论
头像
1 个月前kevin

拆分任务的成本比较高,需要非常有经验,且这个人/团队可能无法替换(k8s本身)

1 个月前NaNa(作者)

就像k8s本身,api-server和controller manager肯定是必要的,没有这些也不能成为k8s。
没有能拆分任务的人/团队,这种方式必然运转不起来。

1 个月前kevin

这里有两层意思,一方面是要有能拆分任务的人,另一方面是任务是可拆分的。映射到k8s的例子就是,k8s适合大规模分布式系统,却不适合强耦合高资源占用的系统,例如模型训练等。

TLDR就是这种分工模式能不能落地,很吃任务/业务类型。是一种新型分工模式,却不一定是一种通用方案

头像
1 个月前greatghoul

挺有想法的。啥时候实践一下

1 个月前NaNa(作者)

https://eleduck.com/posts/Ygf0Da
已经有人在实践了

报酬方式
主要根据任务,设计代码行,设计图,文档量,工作时间量,等多个工作量维度,以及平均难度, 平均投入时间来衡量
鉴于远程工作的不确定性风险,项目经专业团队拆分成小颗粒,通常2到3天工作量。完成即立即支付合作者报酬

异常终止
**本工作室充分理解远程开发协作的交付时间和中断风险,并承担相应风险,远程开发者随时可因任何原因终止协作 **
请在任务约定到期前的任何时间知会本工作室,以便及时处理。约定任务完成时间到达后的1天内,如远程开发者无信息回馈或者失联,默认终止开发协议。
任何异常终止,并不影响后续的合作。

1 个月前greatghoul

很6了。

头像
1 个月前qxhy123

想法挺好, 但是k8s模式对infrastructure是有一定要求的, 人力市场比较难满足这样的要求, 人员是可以随意切换的, 但是人员的素质, 能力包括工作方式这个就很难保证了, 除非有人出钱出力搭建一个这样的人才云, 把人才作为一个infrastructure资源进行筛选, 培训, 封装, 组成一个人员可以无缝切换的人才池.

1 个月前NaNa(作者)

另一个思路,是可以通过比较廉价的招聘方式来筛选应聘者。
常见的实践是开放式0面,即给你3-5天,做一个日常任务相类似的任务,不限是否联网之类。
本身做0面的成本会筛选掉一部分不合适的,然后面试时只要排除代笔的可能性基本上成本还是可控的。

头像
1 个月前186****6817

很有意思的想法,把技术架构的解决问题的思想放到了现实的事件中,希望以后能够形成体系,多分享具体经验!

1 个月前NaNa(作者)

这个不是个人独创,忘了在哪看到的,大意是,组织架构最终会反应到软件架构上。
比如之前单体架构的软件,基本上可能就按分前后端开发,运维,dba之类分组织架构。
等到微服务出来之后,一些企业就对应的将组织架构做了调整。
比如一个team负责一个微服务,如果是到用户端到产品,那这个team里,可能产品,前后端devops都有。一些team负责微服务治理。
不过楼下那个老哥说得好,要结合市场情况来看。

头像
1 个月前ofit

感觉最大的问题是解决工作任务的标准化,毕竟彻底解藕可以随时加入上手的任务不多

1 个月前NaNa(作者)

看上一条评论的回复