一、长桥科技利用Telephone加速业务上线
长桥科技是一家产品技术驱动的金融科技公司，当前为各类型的证券公司外部资管公司，家族办公室，私人银行和超高净值人员提供。可以给客户提供数字化解决方案以及多市场多标的的交易能力以及清算能力。
长桥的 SRE团队负责维护全球多个云厂商，多个 region 的云资源，以及构建在这些云资源之上的众多中间件服务，产品服务等。
虽然管理着如此多的云资源，但是实际上团队一直维持在一个比较小的规模上面。我们用如此小的代价管理如此多的资源是因为从一开始就成是一家 cloud native 的科技公司，从一开始就面临着如何管理这些云资源，传统的国内的公司可能更倾向于使用的 web console ，CLI 或者是 OPEN API 去管理这些资源。但是选择了更好的方案，也就是 IC 的方案。
首先我们是不希望操作是在不断的重复，我们建一个 V switch 要重复好几次操作，然后建一个 ECS 也需要好几次操作，于是希望一次性的就把事情给做对，不用再浪费时间和人力，也可以减少我们的人力的浪费消耗。
所以我们最终选择的是更可复用的一种方案，就是利用 telephone，我们在利用 terraform 的过程中构建了以一个以 get lab ci 为核心的一个 CICD 流程。在业务同事提交了他们的那个资源申请之后，OS同事去把需求转化为 telephone 的模板或者是代码，然后这些资源不仅仅只包括云上的资源，就是通常云厂商提供的 EC SLB 或者是 IDS 的这些云资源。
此外，这些东西还包含了应用的配置，我们会把配置，比如说数据库的配置， MQ 的配置和 volt 的密钥等等都通过telephone 来配置，因为 telephone 它有不同的 provider 提供的这些能力，并且还实现了一套那个自动化流程去配置研发同事去访问这些资源的那个权限配置。通过这些不同的组合，可以把不同层次上的东西去用一种统一的模型去描述来管理。
通过这一整套的流程以及开源社区的能力，团队的每一个人都会去管理我们的云上的资源。甚至还在一些相对比较独立的业务上面有研发同学去管理他们自己业务相关的一些基础设施的配置，带来的好处就是业务开发的角度而言，更需更知道他们的需求是什么，两个团队之间的那个沟通成本就会少很多。第二个好处是这些资源通过 telephone ， gitlab 的能力，可以把资源就是按照一个版本的节奏去发布每一次版本的变更，能够让每个同学清晰的知道这次变更了什么参数，以及它带来的后果是什么。
我们能够清晰知道变化，其次就是万一线上出问题了，可以方便的回退。回退可能只是一个 pipeline 运行的一个时间。第三个好处是能够用一套语言去管理不同的资源。Telephone 提供了能力在一个 project 中去配置不同的 provider 就可以在这一个项目里面配管理不同的，包括阿里云 AWS GCP 都可以去管。其次不同的资源也可以在不同层次上，在一个 project 里面，也就是说在 IDS 中，直接将把它向RDS 内部的数据库的配置， road 的配置，以及哪些人可以访问这些 RDS 的权限都可以直接全部配置了，而不需要在 console 上来回切换。
二、云上基础设施构建与编程规范
transform 本身是基于 HCL 语言来构建的，它是一门编程语言，就要去遵循编程的一些基本的规范。我们希望模块最小化。各个模块之间组合起来可能实现一个更大的一个功能，代码需要被不同的同事所理解，不仅仅是包括我们自己团队内部，还要包括我们团外部团队，甚至是跨国的协作等等。
这样还有一个，第三个就是我们希望这些代码都是可测试的，是经过我们的充分验证后，才能真正的运用到我们的实际的生产环境。还有一个最第四个就是我们希望这些代码都是可测试的，是经过我们的充分验证后，才能真正的运用到实际的生产环境。可以利用各种 provider 提供的原子的能力去配置资源，如果资源足够简单，如写那种编程的时候直接调一个函数就能实现的功能，那就直接用 resource 去解决这些问题。
如果我们的业务更复杂，那就可能需要借助 module 的能力把各种各样的资源组合到模块内部，然后去对外去暴露一个足够小的可配置的一个参数，其实它更好复用在不同的业务上线的时候，可能只要一两分钟就能解决了。
这个最左侧的这个目录是是 telephone 提供的一个最佳实践点 TF 。这个文件其实里面配置的是他本身自己的版本以及所需的各种 provider 的版本。最好是在这个里面去配置第二个back end 就这个点， TF 这个文件是用来配置我们存储的， 一般喜欢会把 state 文件放在 OSS 上，然后用 OTS 去做一些所有的操作，防止并发会有一些问题。
然后 providers TF 这个文件是来放们各种 provider 配置，比如说阿里云，上海以及深圳有各个 region 的配置，我需要再给他们配上 AS 之后，允许在不同的 region 里面去创建各种各样的资源。此外还有 ECS OSS 这这一类资源他推荐的是按照他们实际的用途，比如说计算资源，那就放 ECS 里面 RDS 的资源，按照不同维度的一些资源，不同类型的资源放到各自的目录下面更好去维护。
接下来就是编写代码中间上面这张图实际上展示的是一个 VPC 的配置，下面是展示的是 VPC 的那个改动了一个 VC 的一个网络网段的配置。改完之后通过我的 pipeline 去看的时候得到右边这张图就会看到它一会变更了一个字段，这个字段是一个非常关键的，它的这个 V switch 会被销毁并重新创建一个 vs switch 。如果看到这样的变更，就要非常警惕，因为 for replacement 非常关键，有可能会把 V switch 下面所有的资源全部销毁，接下来就要仔细考虑这个是不是必须要做的。
三、基础设施管理与自动化部署实践
如何去使用 telephone。下面有100行的代码去管理一套基础设施。这个例子里面讲了写的是利用阿里云 ASG 加server group 加 launch template 去配置了一套能够自动伸缩的一套业务。它在节点起来后会被自动注册到我们的那个 LB 后端的 server group 上。写这套配置可能需要花两三个小时。当然这个效率肯定是比不上在 console 上操作或者是 CMI 上操作，但是在 console 上操作可能十分钟就能操作完，但一旦把这个抽象成模块，那在第二个业务、第三个业务出来的提过来类似的需求的时候，只要一分钟，就可以把这一套部署上去。
当然初始写这些东西的时候会相对困难一点，但是后续带来的优势就会非常的明显。比较幸运的是，有很多社区的开发人员会如此做，而且相应的模块，只要拿来就可以用伸手挡。接下来是已经会写模块了，就要考虑如何把这一整套的东西接入我内部系统，如何跟公司内部的流程去做结合，去加速业务上线。
刚才提到长桥科技给全球不同的券商提供数字化解决方案。当有一个新的租户进来，那就会启动这套流程，把租户的信息提交到内部系统上面，只要去点按钮，然后会有一套自动化配置流程的生成的一种方式去提交一大段的那个 telephone 的代码，这段代码就会开始跑 plan ，然后当同学收到相应的通知之后我会去 review 这段配置，可以清晰的看到我这个租户，我要新建多少个库，然后有多少的配置要被写入我们的动态配置中心，还有这会有多少的那个云基础设施会被新建出来，那我们 review 之后，因为这种通常都是比较常规的动作，新建完成便合入了，那合完之后我可能就接下来 apply 之后数据库，数据库 vote 的配置，然后容器的资源就会被自动的创建好这一套我们正常，你如果说是这么多的配数据库，我们可能需要手动操作，或者是找一个外部的数据库管理的一个工具去上线然后把密钥配进去。
通常如果是纯手工操作差不多需要一天的时间一天，但是如果我们用这套配置自动化生成，加上帮我们去管理这些东西，基本上20分钟就可以搞定。有了这系统便可以轻松的实现目标，将任务业务完成的更快。首先用 CI 镜像还是需要在大陆地区，如果将代码库部署在大陆地区的那个镜像以及 provider 最好是能够在本地去把它 cash下载，每次仅需要操作本地的就行，这样操作时间会快很多，其次是因为它会生成一些 state 文件，这样的话可以通过本身开始的能力，把它作为下一个阶段的输入，也可以提升我们整体的apply 的时间，比如说一些是部署在本地的机房，调外部的 API ，或者是调我们国外云厂商的一些 API ，会有一些网络的问题，可能需要去操作系统，这样子做的话会帮助我们减少失败的概率。
在 IC 的那个建设中，其实也不会是一帆风顺。分享一些 tips 。总体来说，不要为了上而上，希望说如果有确实有这种加速的需求，找一个相对小的，独立一点的业务单元来做，不要在公司的主要的业务流程上去做这些新的尝试。因为本身它又相对边缘，然后又比较小，那它就比较模块化一点，也好复用，其次我们要这些新的工具以及新的理念要从测试环境做起，一定要在测试环境上先充分验证过，防止有一些不为人知的小坑点引起更大的线上的故障。
其次就是 gif 的处理，就是在使用的 T 的过程中，难免会碰到我们的那个版本升级，比如说 T 的版本的升级， provider 的版本的升级。会导致它OPEN API 里内部提供的一些字段会和 state 里面的字段有不一致的情况，简单来说，我们可以直接比如说跟类似的下面一样，就是在我们的代码里面去把它的这个偏差给修掉就完成了。
如果说是有相对复杂一点的例子的话，还有中间这种方案就是 life cycle ignore 就可以了，就是这个其实是我在实际用的。过程中发现的一个问题就是我在 ASG 上弹出来的这些节点，它就自动注册到那个 server group 上，他每次 plan 的时候，他会把这个注册上的节点要删掉，这个当然是我们不希望看到了，那我在实际的使用过程中。就会在 life cycle 里面去把这个这个字段给了一个，防止它把注册上的节点又给我从那个 server group 上给摘掉。
这样的话就可以顺畅的去跑这个 pipeline。第三个就是黑科技，把 state 里面的东西删掉，也是在实际实验中使用中碰到的，其实当时这个场景是在 POLO DB 里面，POLO DB 里面加了一个节点，然后class 的这个配置就跟他线上跑不一致了，当时解决办法是要直接把它从里面删掉，又重新操作了一次，状态就就变成正常了。这三个 tips都是在实际生实际使用的过程中碰到的。
以上为分享全部内容。
