Facebook is not important. It has no impact when it's broken.
Started with 2 engineers (myself and another guy) and grew it to about 15. Zero QA, Zero DevOps.
We had CI/CD and a full test suite. We deployed from master as many times a day as we needed / wanted.
It can work if you open your mind to it and you hire the right people who know what they are doing.
Just because it releases quickly and has no QA doesn't mean it's a good thing.
The only metrics that matters is calls from your users. Facebook doesn't even have a number to call when it's broken.
Also: People tend to call the police: http://time.com/3071049/facebook-down-police/
Releasing less often is a way to guarantee that bigger bugs will get through at some point, requiring hotfixes etc. The more you release, the higher quality releases you have, and the smaller production incidents.
The point isn't to remove QA, it's to trust that the automation in place is high quality and will catch the majority of issues before they are issues (i.e. if something makes it through the automation, then it should be caught in the internal release, or at least the 3% canary group), and then on the back of issues, make the automation more robust.
The more people who are introduced into a process, the more likely it is to fail at some point - the fact is that Facebook has a pretty low rate of huge production issues compared to most software companies, they must be doing something right.
Facebook is "7th most valuable company in the world" important.
FTFY