DevOps

我的DevOps之路

My Road Of DevOps

Posted by Zeusro on April 9, 2020
👈🏻 Select language

持续优化是我工作和生活的唯一算法，其一体现就是 DevOps 。

今天讲下我跟 DevOps 相爱相杀的历史。

2016 ~ 2018：static Jenkins

在16年的时候，我就在想怎么提高工作的效率，让应用发布跟得上迭代。

那个时候我也不知道这叫 DevOps 。反正有啥就用啥。最后我选择了 Jenkins 。Jenkins 是一个基于插件的纯瀑布流的CI模型。也就是说，配置是最为繁重的那部分。

image

每一个项目，都需要重复配置（虽然后来我建了一个模板项目，但我发现不能解决根本问题）。每一个项目里面的配置，都包含N个插件。以里面一个Java项目来说。

整个CI的流程，分为

webhook –> Jenkins build –> docker push

Jenkins build 又可细分为

git pull/clone –> gradle/maven build –> docker build

image

这里面每一个步骤，甚至是数据的流动（比如根据tag和branch判定是否需要触发构建）都需要用到插件。

branch插件

以这个项目为例，最终我们使用的插件有：

  1. docker
  2. Environment Injector Plugin
  3. Gitea（源仓库是gitea）
  4. gradle（构建工具用的是gradle）
  5. Mask Passwords（用于掩盖docker login密码）
  6. Generic Webhook Trigger Plugin（就是上图那个 Optional filter 符合输入要求的branch才会触发下一步构建）

除了项目配置，还得做一些全局配置。。。

最终我们会发现， Jenkins变成了一架超级航空母舰，谁也不知道里面放了啥。留下的只是

provider_version=docker image ls $image1 |grep -Eo '([0-9]{0,2}\.){2}[0-9]+'| head -1

这一行最有用的 tag 提取脚本，哈哈哈。。。

结论

小型构建系统（ <30 个构建任务）的最优解

相关工作回顾

  1. 从零开始用Jenkins搭建.NET CI环境
  2. Gogs+Jenkins构建java项目,最后docker化
  3. 在kubernetes上面使用Jenkins

2018 ~ 至今：swarm + Concourse

image

如果说Jenkins 是一个基于插件的纯瀑布流的航空母舰，那么 Concourse 就是极简主义忍者。

Concourse 的最大优点在于可重用的模板配置，其次，活跃的社区也是不错的一个点（说明最起码用的人不少）。而且，他们的 releases 有时候也写的很皮，带点表情包什么的。

缺点在于 breaking change 不少，如果用 docker运行，就会变成 docker in docker。

4.x 版本的时候，出现了无数次 docker hung，load15 过高等状况，当时只能重启。非常滴蛋疼。这个问题，在升级到5.x之后略有缓解。

image

BTW , Concourse 本身是一套分布式系统，未来计划在 Kubernetes 中运行，但目前还只是一个草案

image

结论

2020年3月末发布了6.x版本，值得一试。

相关工作回顾

  1. Concourse-CI集成maven/gradle项目

2020：tektoncd

image

其实，我还折腾过 JenkinsX ,但那时候，JenkinsX 的文档太少，导致工作一直不顺利。JenkinsX 有点像 Jenkins Blue Ocean，还加入点 serverless 。 但他并没有放弃 static Jenkins 那套玩意。最后变得有点不伦不类。

2020/03/11，JenkinsX 宣布自(我)(倒)闭。

函数型 serverless 框架 knative 也宣布放弃自家CI的开发，指向 tektoncd。

在2019年3月的时候，我就已经作为云玩家参与体验了 tektoncd 。那时候，模型的定义还是非常简单。

不过现在上看，当时觉得欠缺的构建缓存现在已经加上去了。不过，2019年我提出的

通过CRD重新定义CI/CD是一大亮点,但目前构建任务只能通过手动创建YAML文件,构建任务一多的时候,集群内就会大量堆积该CI相关的CRD,感觉比较蠢.

这个问题没能很好解决。目前的思路是通过 Cronjob 实现定期清除。

结论

潜力不小，值得一试。

相关工作回顾

  1. 国内服务器安装JenkinsX
  2. Jenkins-X构建Java应用
  3. tektoncd云玩家初体验
  4. Please support build cache in PipelineResources
  5. Can’t rerun existing completed taskruns or delete completed taskruns automatically
  6. Introduce runHistoryLimit

参考链接

  1. Jenkins X选择了Tekton｜将弃用Jenkins
  2. Jenkins X ❤ Tekton

2018.06 ~ 至今：Kubernetes

关于 Kubernetes 我已经发表过无数话题。18年的时候，在稍微了解了一下 Kubernetes 的发布工作流之后（那个时候我对 docker 都不太熟练），我当天立刻决定，就算只有我一个人，我也要在公司内部推广这套系统。

事实证明，我是对的。我们后来又整了一套完整的 DevOps 的体系，Kubernetes 是其中最后，并且最重要的一环。我们从“无运维时代”，直接走向了“无需运维时代”（甩锅给阿里云售后🤣🤣🤣）。

但事实证明，我也是错的。传统应用变成流动的pod之后，要解决

  1. volume
  2. 网络诊断
  3. 资源监控与配额
  4. 云厂商组件bug
  5. docker自身bug
  6. 系统内核（比如IPtable，cgroup，namespace）自身bug

等等一系列问题。随便挑一个都是大问题。。。

结论

没有银弹。但我相信 Kubernetes 是未来10年应用部署的首选模型。

相关工作回顾

  1. Kubernetes系列文章
  2. Kubernetes 中文书

参考链接

  1. 孙健波：Kubernetes 会不会“杀死” DevOps？

2020：阿里巴巴（广告位招租中 ~ ）

这方面的我关注的比较少（分辨是公关文还是技术分享比较浪费时间，所以干脆不看算了）。

阿里巴巴的公司体量比较大，他们遇到的问题和提出的解决方案（比如中台，修改JVM）很多更像是屠龙技，对于小型公司其实没有多大卵用。

不过值得借鉴的地方也有不少。

比如这个 golang 的 Dockerfile，还有云效那套 DevOps 文化。

golang Dockerfile

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

FROM golang:1.14 AS build-env
ADD . /src/github.com/AliyunContainerService/kube-eventer
ENV GOPATH /:/src/github.com/AliyunContainerService/kube-eventer/vendor
ENV GO111MODULE on
WORKDIR /src/github.com/AliyunContainerService/kube-eventer
RUN apt-get update -y && apt-get install gcc ca-certificates
RUN make


FROM alpine:3.10

COPY --from=build-env /src/github.com/AliyunContainerService/kube-eventer/kube-eventer /
COPY --from=build-env /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

ENV TZ "Asia/Shanghai"
RUN apk add --no-cache tzdata
COPY deploy/entrypoint.sh /

ENTRYPOINT ["/kube-eventer"]

云效 DevOps 文化

image

研发模式全自动化

随着“容器化”的浪潮来临，我们研发平台再一次升级，将线上容器定义、运维监控责任全部交给了开发者，应用运维岗位不复存在。

流量回放测试

第二个是流量回放测试技术。这项技术的创新给测试团队带来了很大影响，通过线上流量复制到线下，低成本的解决了测试回归的问题，将传统通过编写用例进行测试，简化为编排数据进行测试。第二层是Mock技术的应用，将一个分布式系统问题，转化为单机问题，可以在几秒钟完成上千个用例运行。有了这两个基础技术后，在上层可以发展测试平台，通过算法的手段去识别有效流量，去自动化处理数据，去识别异常流量背后的缺陷。通过这三层面的变革，可以说让阿里巴巴测试效率有了质的变化。

全链路压测

第三个是全链路压测技术（对应阿里云上的产品叫PTS）。双11大家之所以能放心剁手，一年比一年顺滑，核心就是这项技术在每次大促前帮助开发者发现风险。发现以后就需要快速的响应，通过DevOps工具去解决线上问题。每次压测都是一次练兵，有点类似于军事演习，快速发现问题，快速解决，不断锤炼团队DevOps能力，也可以这样说阿里巴巴的DevOps能力正是一次一次“双11”给练出来的。

大胆尝试，把握底线

image

结论

合适自己的才是最好。

参考链接

  1. 阿里巴巴DevOps文化浅谈
  2. DevOps研发模式下CI/CD实践详解指南

其他可选方案

gocd

理想的DevOp流程怎么做？看看Slack的代码部署实践

总结

DevOps 核心思路只有一个：不断提高应用开发，部署，监控，升级/迭代效率。

Continuous optimization is the only algorithm in my work and life, and one manifestation is DevOps.

Today I’ll talk about my love-hate history with DevOps.

2016 ~ 2018: Static Jenkins

In 2016, I was thinking about how to improve work efficiency and make application releases keep up with iterations.

At that time, I didn’t know this was called DevOps. I just used whatever was available. Finally, I chose Jenkins. Jenkins is a pure waterfall-flow CI model based on plugins. That is to say, configuration is the most burdensome part.

image

Every project needed repeated configuration (although I later created a template project, I found it couldn’t solve the fundamental problem). Every project’s configuration contained N plugins. Take a Java project inside as an example.

The entire CI process is divided into:

webhook –> Jenkins build –> docker push

Jenkins build can be further subdivided into:

git pull/clone –> gradle/maven build –> docker build

image

Every step here, even data flow (like determining whether to trigger a build based on tag and branch), requires plugins.

branch plugin

Taking this project as an example, the plugins we ultimately used were:

  1. docker
  2. Environment Injector Plugin
  3. Gitea (source repository is gitea)
  4. gradle (build tool is gradle)
  5. Mask Passwords (for masking docker login passwords)
  6. Generic Webhook Trigger Plugin (the Optional filter in the image above—only branches that meet input requirements will trigger the next build step)

Besides project configuration, we also had to do some global configuration…

In the end, we’ll find that Jenkins became a super aircraft carrier, and no one knows what’s inside. What remains is just:

provider_version=docker image ls $image1 |grep -Eo '([0-9]{0,2}\.){2}[0-9]+'| head -1

This most useful tag extraction script, hahaha…

Conclusion

Optimal solution for small build systems (<30 build tasks)

  1. Building .NET CI Environment with Jenkins from Scratch
  2. Gogs+Jenkins Building Java Projects, Finally Dockerized
  3. Using Jenkins on Kubernetes

2018 ~ Present: Swarm + Concourse

image

If Jenkins is a pure waterfall-flow aircraft carrier based on plugins, then Concourse is a minimalist ninja.

Concourse’s biggest advantage is reusable template configuration. Second, an active community is also a good point (showing at least many people use it). Moreover, their releases are sometimes written quite playfully, with some emojis and stuff.

The downside is there are many breaking changes. If running with docker, it becomes docker in docker.

In version 4.x, there were countless instances of docker hung, load15 too high, etc. At that time, we could only restart. Very annoying. This problem was slightly alleviated after upgrading to 5.x.

image

BTW, Concourse itself is a distributed system, with plans to run in Kubernetes in the future, but currently it’s just a draft

image

Conclusion

Version 6.x was released at the end of March 2020, worth a try.

  1. Concourse-CI Integrating maven/gradle Projects

2020: tektoncd

image

Actually, I also messed around with JenkinsX, but at that time, JenkinsX documentation was too scarce, causing work to be constantly unsuccessful. JenkinsX is a bit like Jenkins Blue Ocean, with some serverless added. But it didn’t abandon the static Jenkins stuff. Finally, it became a bit neither fish nor fowl.

On 2020/03/11, JenkinsX announced self-(my)(collapse).

The functional serverless framework knative also announced abandoning its own CI development, pointing to tektoncd.

In March 2019, I had already participated as a cloud player to experience tektoncd. At that time, the model definition was still very simple.

But looking at it now, the build cache that I thought was missing has now been added. However, what I proposed in 2019:

Redefining CI/CD through CRD is a major highlight, but currently build tasks can only be created manually through YAML files. When there are many build tasks, CI-related CRDs will accumulate heavily in the cluster, which feels quite stupid.

This problem wasn’t solved well. The current approach is to implement periodic cleanup through Cronjob.

Conclusion

Great potential, worth a try.

  1. Installing JenkinsX on Domestic Servers
  2. Jenkins-X Building Java Applications
  3. tektoncd Cloud Player First Experience
  4. Please support build cache in PipelineResources
  5. Can’t rerun existing completed taskruns or delete completed taskruns automatically
  6. Introduce runHistoryLimit

References

  1. Jenkins X Chose Tekton｜Will Abandon Jenkins
  2. Jenkins X ❤ Tekton

2018.06 ~ Present: Kubernetes

I’ve published countless topics about Kubernetes. In 2018, after slightly understanding Kubernetes’ release workflow (at that time I wasn’t even very familiar with docker), I immediately decided that day that even if I was the only one, I would promote this system within the company.

Facts proved I was right. We later built a complete DevOps system, and Kubernetes was the last and most important link. We went directly from the “no operations era” to the “no need for operations era” (passing the buck to Alibaba Cloud after-sales 🤣🤣🤣).

But facts also proved I was wrong. After traditional applications became flowing pods, we needed to solve:

  1. volume
  2. Network diagnosis
  3. Resource monitoring and quotas
  4. Cloud vendor component bugs
  5. Docker’s own bugs
  6. System kernel (like IPtable, cgroup, namespace) bugs

And a series of other problems. Any one of them is a big problem…

Conclusion

No silver bullet. But I believe Kubernetes is the preferred model for application deployment in the next 10 years.

  1. Kubernetes Series Articles
  2. Kubernetes Chinese Book

References

  1. Sun Jianbo: Will Kubernetes “Kill” DevOps?

2020: Alibaba (Advertising Space for Rent ~)

I pay less attention to this aspect (distinguishing between PR articles and technical sharing is a waste of time, so I just don’t look).

Alibaba’s company scale is relatively large. The problems they encounter and solutions they propose (like middle platform, modifying JVM) are more like dragon-slaying skills, not very useful for small companies.

But there are also many places worth learning from.

Like this golang Dockerfile, and that DevOps culture from Cloud Efficiency.

golang Dockerfile

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

FROM golang:1.14 AS build-env
ADD . /src/github.com/AliyunContainerService/kube-eventer
ENV GOPATH /:/src/github.com/AliyunContainerService/kube-eventer/vendor
ENV GO111MODULE on
WORKDIR /src/github.com/AliyunContainerService/kube-eventer
RUN apt-get update -y && apt-get install gcc ca-certificates
RUN make


FROM alpine:3.10

COPY --from=build-env /src/github.com/AliyunContainerService/kube-eventer/kube-eventer /
COPY --from=build-env /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

ENV TZ "Asia/Shanghai"
RUN apk add --no-cache tzdata
COPY deploy/entrypoint.sh /

ENTRYPOINT ["/kube-eventer"]

Cloud Efficiency DevOps Culture

image

Fully Automated R&D Mode

With the wave of “containerization” coming, our R&D platform upgraded again, handing all online container definitions and operations monitoring responsibilities to developers. The application operations position no longer exists.

Traffic Replay Testing

The second is traffic replay testing technology. This technological innovation had a great impact on the testing team. By copying online traffic offline, it low-cost solved the problem of test regression, simplifying traditional test case writing to test data orchestration. The second layer is the application of Mock technology, transforming a distributed system problem into a single-machine problem, completing thousands of test case runs in seconds. With these two foundational technologies, a testing platform can be developed at the upper layer, using algorithmic means to identify effective traffic, automatically process data, and identify defects behind abnormal traffic. Through these three levels of transformation, it can be said that Alibaba’s testing efficiency has had a qualitative change.

The third is full-link pressure testing technology (corresponding to the product on Alibaba Cloud called PTS). The reason everyone can confidently shop during Double 11, getting smoother year by year, is that this technology helps developers discover risks before each major promotion. After discovery, rapid response is needed, using DevOps tools to solve online problems. Each pressure test is a training exercise, somewhat similar to military exercises—quickly discovering problems, quickly solving them, continuously honing the team’s DevOps capabilities. It can also be said that Alibaba’s DevOps capabilities were trained through one “Double 11” after another.

Bold Attempts, Grasp the Bottom Line

image

Conclusion

What suits you is best.

References

  1. Alibaba DevOps Culture Discussion
  2. Detailed Guide to CI/CD Practice in DevOps R&D Mode

Other Optional Solutions

gocd

How to Do the Ideal DevOps Process? Look at Slack’s Code Deployment Practice

Summary

DevOps has only one core idea: continuously improve application development, deployment, monitoring, upgrade/iteration efficiency.

Непрерывная оптимизация — единственный алгоритм в моей работе и жизни, и одно из его проявлений — это DevOps.

Сегодня я расскажу о моей истории любви-ненависти с DevOps.

2016 ~ 2018: Static Jenkins

В 2016 году я думал о том, как повысить эффективность работы и заставить выпуски приложений успевать за итерациями.

В то время я не знал, что это называется DevOps. Просто использовал то, что было доступно. В итоге я выбрал Jenkins. Jenkins — это чистая модель CI с водопадом на основе плагинов. То есть, конфигурация — самая обременительная часть.

image

Каждый проект требовал повторной конфигурации (хотя позже я создал шаблонный проект, но обнаружил, что он не может решить фундаментальную проблему). Конфигурация каждого проекта содержала N плагинов. Возьмём в качестве примера проект Java внутри.

Весь процесс CI делится на:

webhook –> Jenkins build –> docker push

Jenkins build можно далее подразделить на:

git pull/clone –> gradle/maven build –> docker build

image

Каждый шаг здесь, даже поток данных (например, определение необходимости запуска сборки на основе tag и branch), требует плагинов.

branch plugin

В качестве примера этого проекта, плагины, которые мы в конечном итоге использовали:

  1. docker
  2. Environment Injector Plugin
  3. Gitea (исходный репозиторий — gitea)
  4. gradle (инструмент сборки — gradle)
  5. Mask Passwords (для маскировки пароля docker login)
  6. Generic Webhook Trigger Plugin (это Optional filter на изображении выше — только ветки, соответствующие входным требованиям, запустят следующий шаг сборки)

Помимо конфигурации проекта, также нужно было делать некоторую глобальную конфигурацию…

В конечном итоге мы обнаружим, что Jenkins стал супер-авианосцем, и никто не знает, что внутри. Осталось только:

provider_version=docker image ls $image1 |grep -Eo '([0-9]{0,2}\.){2}[0-9]+'| head -1

Этот самый полезный скрипт извлечения тега, хахаха…

Заключение

Оптимальное решение для небольших систем сборки (<30 задач сборки)

Обзор связанной работы

  1. Создание .NET CI-окружения с Jenkins с нуля
  2. Gogs+Jenkins Сборка Java-проектов, наконец Dockerized
  3. Использование Jenkins на Kubernetes

2018 ~ Настоящее время: Swarm + Concourse

image

Если Jenkins — это чистый водопадный авианосец на основе плагинов, то Concourse — это минималистский ниндзя.

Самое большое преимущество Concourse — это переиспользуемые шаблонные конфигурации. Во-вторых, активное сообщество — тоже хороший момент (показывает, что по крайней мере многие люди используют его). Более того, их релизы иногда написаны очень игриво, с некоторыми эмодзи и прочим.

Недостаток в том, что breaking changes много, и если запускать с docker, это становится docker in docker.

В версии 4.x было бесчисленное количество случаев docker hung, load15 слишком высокий и т.д. В то время можно было только перезапустить. Очень раздражало. Эта проблема была немного облегчена после обновления до 5.x.

image

Кстати, Concourse сам по себе — это распределённая система, с планами запуска в Kubernetes в будущем, но в настоящее время это всего лишь черновик

image

Заключение

Версия 6.x была выпущена в конце марта 2020 года, стоит попробовать.

Обзор связанной работы

  1. Concourse-CI Интеграция проектов maven/gradle

2020: tektoncd

image

На самом деле, я также возился с JenkinsX, но в то время документация JenkinsX была слишком скудной, что приводило к постоянным неудачам в работе. JenkinsX немного похож на Jenkins Blue Ocean, с добавлением некоторого serverless. Но он не отказался от вещей static Jenkins. В итоге стал немного ни рыбой ни мясом.

11.03.2020, JenkinsX объявил о само(мо)(за)крытии.

Функциональный serverless-фреймворк knative также объявил об отказе от собственной разработки CI, указывая на tektoncd.

В марте 2019 года я уже участвовал как облачный игрок, чтобы испытать tektoncd. В то время определение модели было ещё очень простым.

Но теперь, глядя на это, кэш сборки, который я тогда считал недостающим, уже добавлен. Однако, то, что я предложил в 2019 году:

Переопределение CI/CD через CRD — это большой момент, но в настоящее время задачи сборки можно создавать только вручную через YAML-файлы. Когда задач сборки много, в кластере будет накапливаться много CRD, связанных с этим CI, что кажется довольно глупым.

Эта проблема не была хорошо решена. Текущий подход — реализовать периодическую очистку через Cronjob.

Заключение

Большой потенциал, стоит попробовать.

Обзор связанной работы

  1. Установка JenkinsX на внутренних серверах
  2. Jenkins-X Сборка Java-приложений
  3. tektoncd Первый опыт облачного игрока
  4. Please support build cache in PipelineResources
  5. Can’t rerun existing completed taskruns or delete completed taskruns automatically
  6. Introduce runHistoryLimit

Ссылки

  1. Jenkins X Выбрал Tekton｜Откажется от Jenkins
  2. Jenkins X ❤ Tekton

2018.06 ~ Настоящее время: Kubernetes

Я опубликовал бесчисленные темы о Kubernetes. В 2018 году, после небольшого понимания рабочего процесса выпуска Kubernetes (в то время я даже не был очень знаком с docker), я сразу же в тот же день решил, что даже если я один, я буду продвигать эту систему внутри компании.

Факты доказали, что я был прав. Мы позже построили полную систему DevOps, и Kubernetes был последним и самым важным звеном в ней. Мы перешли прямо от “эры без операций” к “эре без необходимости в операциях” (переложив вину на послепродажное обслуживание Alibaba Cloud 🤣🤣🤣).

Но факты также доказали, что я был неправ. После того, как традиционные приложения стали текучими pods, нужно было решить:

  1. volume
  2. Диагностика сети
  3. Мониторинг ресурсов и квоты
  4. Ошибки компонентов облачных поставщиков
  5. Собственные ошибки docker
  6. Собственные ошибки системного ядра (например, IPtable, cgroup, namespace)

И ряд других проблем. Любая из них — большая проблема…

Заключение

Нет серебряной пули. Но я верю, что Kubernetes — это предпочтительная модель для развёртывания приложений на следующие 10 лет.

Обзор связанной работы

  1. Серия статей Kubernetes
  2. Китайская книга Kubernetes

Ссылки

  1. Сунь Цзяньбо: Убьёт ли Kubernetes DevOps?

2020: Alibaba (Рекламное место сдаётся в аренду ~)

Я обращаю меньше внимания на этот аспект (различение PR-статей и технических обменов — пустая трата времени, поэтому просто не смотрю).

Масштаб компании Alibaba относительно велик. Проблемы, с которыми они сталкиваются, и решения, которые они предлагают (например, средняя платформа, изменение JVM), больше похожи на навыки убийства драконов, не очень полезные для небольших компаний.

Но есть также много мест, заслуживающих изучения.

Например, этот Dockerfile для golang, и та культура DevOps от Cloud Efficiency.

golang Dockerfile

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

FROM golang:1.14 AS build-env
ADD . /src/github.com/AliyunContainerService/kube-eventer
ENV GOPATH /:/src/github.com/AliyunContainerService/kube-eventer/vendor
ENV GO111MODULE on
WORKDIR /src/github.com/AliyunContainerService/kube-eventer
RUN apt-get update -y && apt-get install gcc ca-certificates
RUN make


FROM alpine:3.10

COPY --from=build-env /src/github.com/AliyunContainerService/kube-eventer/kube-eventer /
COPY --from=build-env /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

ENV TZ "Asia/Shanghai"
RUN apk add --no-cache tzdata
COPY deploy/entrypoint.sh /

ENTRYPOINT ["/kube-eventer"]

Культура DevOps Cloud Efficiency

image

Полная автоматизация режима R&D

С приходом волны “контейнеризации” наша платформа R&D снова обновилась, передав все обязанности по определению онлайн-контейнеров и мониторингу операций разработчикам. Позиция операций приложений больше не существует.

Тестирование воспроизведения трафика

Второе — это технология тестирования воспроизведения трафика. Инновация этой технологии оказала большое влияние на команду тестирования. Путём копирования онлайн-трафика офлайн, она низкозатратно решила проблему регрессии тестирования, упростив традиционное тестирование через написание тестовых случаев до оркестрации данных для тестирования. Второй слой — это применение технологии Mock, преобразующей проблему распределённой системы в проблему одной машины, способную выполнить тысячи тестовых случаев за несколько секунд. С этими двумя базовыми технологиями на верхнем уровне можно разработать платформу тестирования, используя алгоритмические средства для идентификации эффективного трафика, автоматической обработки данных и идентификации дефектов за аномальным трафиком. Через эти три уровня трансформации можно сказать, что эффективность тестирования Alibaba претерпела качественные изменения.

Полное тестирование под нагрузкой всей цепочки

Третье — это технология полного тестирования под нагрузкой всей цепочки (соответствующий продукт на Alibaba Cloud называется PTS). Причина, по которой все могут уверенно делать покупки во время Double 11, становясь всё более плавными год за годом, заключается в том, что эта технология помогает разработчикам обнаруживать риски перед каждой крупной акцией. После обнаружения требуется быстрый ответ, используя инструменты DevOps для решения онлайн-проблем. Каждое тестирование под нагрузкой — это тренировка, несколько похожая на военные учения — быстрое обнаружение проблем, быстрое решение, постоянная отработка способностей команды DevOps. Можно также сказать, что способности DevOps Alibaba были отточены через одно “Double 11” за другим.

Смелые попытки, удержание дна

image

Заключение

То, что подходит вам, лучше всего.

Ссылки

  1. Обсуждение культуры DevOps Alibaba
  2. Подробное руководство по практике CI/CD в режиме R&D DevOps

Другие варианты

gocd

Как сделать идеальный процесс DevOp? Посмотрите на практику развёртывания кода Slack

Резюме

DevOps имеет только одну основную идею: непрерывно повышать эффективность разработки, развёртывания, мониторинга, обновления/итерации приложений.

CATALOG
你已经读了 0%
    FEATURED TAGS
    C# Kubernetes Java P DevOps n go code give up cloud native time Elasticsearch AI Devops GitHub Linux mysql
    FRIENDS