一、总篇

为不断的项目增加及不断的人员扩充,建立一个可复用的管理模式。

主要指导原则:

  • 透明
  • 可预期、可确认、可溯源(有痕迹)、可复用
  • 质量与速度并重、有序推进

二、基于技术代号的组织模式

以技术代号,做为项目的组织模式。通过代号关联项目相关的所有内容。

技术代号以简短的英文单词为佳(也可以理解为它是项目的花名)。下面内容以代号demo为例:

(一)专用项目组

  • 建立配套的专用项目组,项目组代号:demo(项目组为横向虚拟结构)
  • 关键配置:产品经理(为项目经理) + 技术牵头人(为项目副经理)
    • 以产品为驱动力,技术为实现力,架构为支撑力
    • 技术牵头人为技术人员的总接口,负责与产品协调及技术之外的协调
    • 所有与技术相关的交流,技术牵头人须同时在场

(二)原型与设计资料管理

原始资料:

  • 原型文件名格式:demo-子项目名-版本
  • 设计源文件名格式:demo-子项目名-版本-xx (xx为其它信息)

目录管理,或云端管理(如蓝湖):

  • 目录名或空间名:demo (如果有空间概念)
  • 项目名:demo-子项目名

(三)词条管理、计划管理、问题管理、工单管理,基于TeamX

  • 建立计划空间:demo。并建立子计划,计划名例:(格式:代号-子项目-版本号、代号-平台-版本号)
    • demo-应用接口-1.2
    • demo-安卓-1.2
  • 建立测试空间:demo。问题分组名例:(格式:demo-平台)
    • demo-安卓
  • 建立WIKI空间:demo。空间名:(格式:demo)
    • demo
关于计划制定的基本规范:

1. 计划争对原型逻辑、功能、视图,不断拆解;拆为单任务4小时内完成,为一个工作项。(特殊情况除外)
2. 经办人为1人,其它协办人做为备注部分
3. 对工作项进行必要分组。从而呈现更良好的观感
4. 由技术牵头人组织相关计划制定

(四)源码管理,基于 GitLab

源码路径格式:主域-代号-项目名

  • 建立主域:data.code
  • 建立项目域:data.code/demo , 子项目名例:(格式:demo-语义性的子项目名)
    • demo-api
    • demo-admin-ui
    • demo-admin-api
    • demo-factor-ui
    • demo-factor-api
    • demo-job
所有项目打包成jar,使用自带boot,最后转为 systemctl service 进行控制;或者打包成 docker 镜像由 k8s 进行控制。

(五)运维工件管理

非容器方案:

所有运维资料放在/data/路径,基本结构:

/data/www/{域名}  #放置网站内容
/data/sss/{代号}  #放置jar服务
/data/_nginx.conf/{域名}  #放置nginx代理配置

以部署water服务为例:

#网站,没有

#服务
/data/sss/water/waterapi.jar
/data/sss/water/wateradmin.jar
/data/sss/water/waterpaas.jar
/data/sss/water/waterraas.jar
/data/sss/water/watersev.jar

#代理配置
/data/_nginx.conf/water  #此域为water
/data/_nginx.conf/admin.water.io  #此域为admin.water.io

容器方案:

打包成docker镜像,由k8s管理。基本要求:

  • 以代号建立同名域
  • 同个域下的服务端口保持不重复
  • 所有服务要兼容ip漂移

三、项目虚拟组协作模式

(一)交流机制

  • 建立项目专用交流群组:demo,相关业务与技术问题,在此群交流。群名例:(格式:代号-项目组)
    • demo-项目组(建议使用QQ讨论组)

对不同的IM平台,可以做场景划分。比如:

  • QQ群做为研发项目组交流
  • 微信群做为运营问题交流
  • 钉钉做为行政与人事问题交流
  • 避免点对点的交流风格(适合单项目人少)//人多时易混乱,各人得到的信息不同

  • 提倡小组与寄头人的交流风格(适合多项目人多)//信息传达会衰减,可用各种代表会议补充

  1. 与项目组技术交流时,技术牵头人需在场(有利于各种情况的积累)
  2. 与项目组业务交流时,产品经理需在场(有利于各种情况的积累)
  • 人员关系组织有序

(二)协作主流程与三三模式与计划

  • 所有评审,技术牵头人须参加
  • 技术设计,主要包括:架构设计、接口设计等。。。技术牵头人须组织小组人员基于原型及产品逻辑,以会议形式进行评审确认。

三三模式:

  • 设计阶段,大概占1/3工期
  • 实现阶段,大概占1/3工期
  • 测试验收阶段,大概占1/3工期

计划制定:

  • 以一个主题或发布周期为一个计划
  • 计划周期过长或存在不确定因素时,可拆分为多期计划(例:一期、二期)
  • 内容要包括制定计划本身的相关工作
  • 须以4小时左右为时间单位进行不断拆解,并进行分组
  • 须以三三模式推导出测试与验收计划,并编制独立计划文件

完整的计划包括开发计划与测试验收计划,过程:

  • 技术人员定制开发计划
  • 测试人员在开发计划的时间基础上,以三三模式定制自己的测试计划(建议70%为测试时间;30%为验收时间)

(三)嘀嗒模式(制度性保障输出质量)

  • 嘀,为产品能力增强(加功能)
  • 嗒,为产品或技术优化(做优化)

以质量为导向。让处理慢下来,且有节奏和规划,并提搞质量。

例1:嘀嗒嘀嗒嘀嗒...

例2:嘀嘀嗒嘀嘀嗒嘀...

(四)产品设计评审流程

(五)技术设计评审流程

其中,计划的制定分了两个阶段。

(六)测试设计评审

测试的用例及评审,如果发现产品问题可反馈给产品经理(协助进一步完善产品)。

(七)虚拟组例会模式

每周最少开一次例会(周一或周五)。增加小组透度度,及关键问题交流。初期可以多开点,后期可以少开点。

(八)问题等级响应模式

  • 红色级:已有生产能力,出现问题。
    • 服务器原因:即时处理
    • 后端原因:即时安排处理
    • 客户端原因:优先安排处理
  • 橙色级:急需增加的生产能力,比如影响业务闲环的。可优先排期、适当加班调休
  • 黄色级:关键生产能力。按节奏排期,不可跳过
  • 蓝色级:常规生产能力建设

(九)问题响应流程

(十)优化响应流程

四、基于虚似组的团队结构模式

(一)团队结构模式

(三)内网研发平台模式

  • 建立平台导航
  • 基于LDAP建立统一账号
  • 选用基于LDAP体系的工具
  • 基于VPN构建行为记录入安全域

(三)项目组的规划推演模式

五、开发架构模式

(一)工程文件组织模型

(二)平台架构概况

六、运维简易操作模式

(一)服务器初始化要求(非容器模式)

所有运维资料放在/data/路径,基本结构:

/data/www/{域名}  #放置网站内容
/data/sss/{代号}  #放置jar服务
/data/_nginx.conf/{域名}  #放置nginx代理配置

(二)基于Systemctl service模式管理服务(非容器模式)

systemctl service 配置,waterapi为例:/etc/systemd/system/waterapi.service

[Unit]
Description=waterapi
After=syslog.target

[Service]
ExecStart=/usr/bin/java -jar /data/sss/water/waterapi.jar --white=0
SuccessExitStatus=143
SuccessExitStatus=143
Restart=on-failure

[Install]
WantedBy=multi-user.target

通过 systemctl 指令操控服务:

systemctl enable waterapi

systemctl restart waterapi

systemctl stop waterapi

配置好后之后,服务更新的简单操作:

  1. 更新 jar 文件
  2. 运行 systemctl restart waterapi 即可

(三)运维相关密码的基本要求

  1. 长度为16位
  2. 密码同时含有大小写字母、数字、_等特殊符号
  3. 密码由工具生成

(四)环境规划及预发环境

环境特别说明
开发与内测环境开发与内测共享数据库。测试环境,基于k8s构建
预生产环境(或外测环境)完全独立的环境,定期从生产环境导入数据库。基于k8s构建。(非常重要的环境)
生产环境

工件发布的流程概要:

  • 测试阶段,在测试环境完成测试;
  • 验收阶段,在预发环境完善测试,并最终生产环境复核。

(五)基于环境的域名规划范例

  • 生产环境,域名规划,例:
模式1:{sev}.xxx.com
模式2:api.{sev}.xxx.com

# 例:
api.app.xxx.com
api.admin.xxx.com
  • 预生产环境或外测环境,域名规划,例:
模式1:rc.{sev}.xxx.com
模式2:rc.api.{sev}.xxx.com

# 例:
rc.api.app.xxx.com
rc.api.admin.xxx.com
  • 开发与内测环境,域名规划,例:
模式1:dev.{sev}.xxx.com
模式2:dev.api.{sev}.xxx.com

# 例:
dev.api.app.xxx.com
dev.api.admin.xxx.com

(六)运维上线工单流程

原则上周五禁止发布工件。

七、源码简易控制与自动化部署模式

  • 部署包或镜像去状态化:
    • 本地不存储数据,如:本地日志、本地图片等...
    • 环境无关性。即环境信息基于配置服务,且配置服务基于固定的域
  • 每次版本发布之后,项目相关的所有工程全部打上统一的tags(不管有没有变更的)
  • 版本号采用三段式风格
    • 例:1.3.0
  • tags 命名风格:
    • tag-1.3.0
    • tag-1.3.0-20210308
    • tag-1.3.0-20210308-简要说明

八、环境隔离与网络安全模式

九、办公账号与密码管理模式

(一)两级强密码方案

一级强密码方案(主要用于普通办公):

  1. 长度为8位
  2. 密码同时含有大小写字母、数字
  3. 密码由工具生成

例:zaYuLci6

二级强密码方案(主要用于运维办公或重要资源):

  1. 长度为16位
  2. 密码同时含有大小写字母、数字、_等特殊符号
  3. 密码由工具生成

例:5fXJcJ*9@sSXF@mz

(二)三级账号方案

一级账号方案(一般用内部办公):

采用人员真名或花名全拼;有冲突时采用年份结尾。例:刘备,liubei 或 liubei81

二级账号方案(一般用于资源账号):

采用人员英文名或代号 + 数字。例:saga03 或 water

三级账号方案(一般用于敏感账号):

采用一级强密码方案生成。例:L8XzZTFK

(三)LDAP账号体系应用

LDAP应用范围(所有支持的内部系统):

  1. GitLab(源码管理)
  2. TeamX(团队协作)
  3. Nexus
  4. OpenVPN
  5. Yapi(接口管理)
  6. 等...

LDAP账号:

采用一级账号命名方案。例:刘备,liubei

LDAP账号密码:

采用一级强密码方案。例:X6xxWc37

(四)外部资源及账号统一管理

运维资源及账号:

  1. 统一由运维经理整理成册
  2. 并由技术负责人或指定专人备案(不得登录操作)。

开发与生产资源及账号:

  1. 统一由技术助理整理成册(不得登录操作)
  2. 并由技术负责人、运营负责人或指定专人备案。

运营资源及账号:

  1. 统一由运营助理整理成册(不得登录操作)
  2. 并由运营负责人或指定专人备案。

资源账密码要求:

视情况,采用不同的密码与账号方案

十、技术支撑中台模式

(一)日志服务模式

(二)配置服务模式

(三)事件总线模式

(四)FaaS模式

(五)监控模式

(六)告警模式

(七)链路关联模式

(八)辅助开发模式

(九)辅助运维模式

3333333333

eeeeeeeeeeeeeeeeeeeeeeeeeeeeee

2

2222222222222222222222222