lvhuiyang

@Philippa 感谢回复，很好的建议，我再调研一下。

@Or13rs 感谢回复，很宝贵的经验。 我目前管理的项目规模还不大，觉得上面提到的 Airflow 的问题也还可以接受，总之很感谢分享这些经验，我再调研一下

@ddkk1112 @quanqqqq 感谢回复，嗯预期是使用 postgres 作为数据库的

@David1119 感谢回复，之前用过 airflow 所以会优先考虑 airflow 了，倒是可以对比一下 perfect

@PeiXyJ 感谢回复，引入 Docker 是为了方便运行不同语言环境的项目，这些项目本身是 Docker 部署的，有对应的 image 管理，所以相对比较方便。

@irainsoft 感谢回复，我去了解一下

#6 @BeautifulSoap 十分感谢回复，经过排查确实是我的程序内部逻辑问题：在 lambda 内部使用 sdk 调用 secretsmanager client 的 get_secret_value 时候默认未设置超时时间，导致有一定概率会卡住：

```python
session = boto3.session.Session()
client = session.client(
service_name="secretsmanager",
region_name=REGION_NAME,
config=aws_client_config,
)
response = client.get_secret_value(SecretId=db_secret_id)
```

虽然还不清楚在 lambda 内部使用 sdk 调用 secretsmanager client 会啥可能卡住，目前换了其他的方式来避免调用 secretsmanager client 之后，原来的问题解决了。

#2 #3 @Aygnh136

明白了，我对 lambda 的理解确实有问题，我再去了解一下，十分感谢回复

#1 @Mithril 非常感谢回复，看来我对 lambda 的冷启动理解有问题，查了下日志确实是大量 Init Duration

对冷启动时间倒是不是很敏感，敏感的是因为超时带来的请求错误。通过日志看冷启动时间不超过 1s ，业务处理逻辑应该在 200 ms 以内，因此设置了 5s 的超时时间应该是足够的。但是错误率确实和超时时间有关，我再定位一下吧，总之十分感谢提供的信息

日志查询 Init Duration：


错误率确实和允许时常有关 ：