微服务架构它的特点之一是服务太多，很难保障所有的服务都是可用的，有可能出现这样的一个情况就是晚上上线的时候，产品的各个业务形态都是正常的，但是到第二天的时候，某个服务由于某些问题导致服务不可用然后影响到具体的业务形态，从而影响到客户的使用，接着而来的就是各种复盘以及问题的追究，这种是最让人头疼的。也会让业务交付的团队承担不应该属于自己的问题。那么这就涉及一个很核心的问题，这问题到底是谁的责任了？总不能让运维去承担吧。所以应该设法去解决找到服务不可用的原因。

一个上线完好的产品会在什么状态下服务不可用，可能这中间存在OOM，队列堵塞，线程死锁等其他异常情况，让服务出现崩溃，从而导致服务不可用。首先所有的服务都无法人为或者技术保障来做到万无一失，那么就需要思考的是在出现问题的情况下，如何能够快速的知晓问题以及进行紧急的修复问题，从而减少客户的影响，让服务可持续的交付市场。这种情况下，可以使用线上巡检机制。