TL;DR：扩展应用服务计划并缩减。
在我与MSFT在团队上打了一个支持电话后，这个问题现在解决了（我的雇主与MSFT有一个非常高的SLA，在提交请求后两个小时内就联系了我），请在这里查看我的总结：
支持工程师发现与应用服务的vNet相关的错误，并建议断开应用服务与vNet的连接。我们这样做了，问题得到了解决-scm网站不再抛出503错误。
我们再次启用vNet连接，scm站点再次开始给予503错误。我们以为我们知道原因是vNet。
然后，我们保持vNet连接，并扩大应用服务计划并缩减-这将导致应用服务迁移到另一个VM示例。在那之后-scm仍然工作！
所以我们不知道是不是vNet造成了问题。底层VM可能出错了。

我也有同样的问题。很难搞清楚到底发生了什么事因为503号在Kudu。在我最近的案例中，vnet也有问题，但是任何扩展都不能解决这个问题。当我从vnet断开应用程序服务时，kudu开始工作，但我希望它在vnet内部。**碰巧我在一个地方有vnet，在另一个地方有app服务。**一切都是通过terraform设置的。此配置不会触发任何警报，但显然不可能以这种方式设置。**当我把所有东西都放在一个位置时，问题就解决了。**也许也可以有两个vnet，每个位置一个，然后把它们放在一起（还没有测试过，但似乎也是一个很好的解决方案）。
所以请记住，Kudu上的503很可能与网络的设置方式有关。
PS：我不得不使用不同的应用程序服务位置，因为我在西欧尝试提供应用程序计划时不断得到一个错误，说明该地区没有另一个虚拟机的容量，这就是为什么我创建了应用程序计划在北欧。我就是这样来到这里的。

另一种可能发生这种情况的可能性是在错误的ARM部署中，Linux的Azure应用服务计划没有将reserved属性设置为true，尽管Linux计划，操作系统默认为Windows。部署到该计划的任何应用服务，无论配置是否正确，都将看起来准备好接受代码部署，但不会成功启动。
RobReagan的评论是正确的，这不应该发生在正确创建的资源中，即使是失败的代码部署。

我的应用程序服务计划运行大约10个应用程序，内存为93%。我关闭了其中一个应用程序，它掉在80%内存的某个地方，我可以再次访问SCM站点。
值得一试。