I see two major philosophies that underpin  approaches to achieving reliability  in the software industry. In brief, they are
Reliability is achieved through engineering quantitive systems and processes that provide correct choices to tradeoff decisions
Reliability emerges from nurturing an ecology that learns to adapt to changing conditions
Based on loose parallels to Hollnagel's safety science work, we might name these reliability-i and reliability-ii. Unfortunately, this could implicitly suggest that reliability-ii is better than, "after", or completely distinct from reliability-i. Instead, I'll designate them “angled reliability” and “curved reliability” . My main observations from these definitions are
Angled reliability is (relatively more) aligned with SRE, SLIs, etc 
Industry has generally focused on angled reliability
Explicit, visible industry efforts in curved reliability have been few and far between 
Based on my explorations over the past few months, I believe (vs observe) that
The increasing velocity and complexity of the software industry will lead to curved reliability increasing in importance and value
A major challenge to organizational investment in curved reliability is the ability to make its value legible to leadership while simultaneously avoiding oversimplification
"Success" involves the composition of angled and curved reliability
If this resonates or if you have thoughts, drop me a tweet? This writeup sacrifices completeness for brevity—I'm happy to get into the details if you have questions! You may also be interested in the blog and/or newsletter of Learning from Incidents in Software.
 via fundamental beliefs and assumptions, e.g. about system linearity, the existence of human error, etc
 however you'd like to define it! A colloquial, common sense, and/or slightly ambiguous definition should be fine for our purposes.
 To me, “angled” responsibility evokes the “crunchy” nature of metrics & etc. Plus, slightly clunky names may help avoid buzzword-coining.
 here we'll use Google's definitions from the Site Reliability Engineering book
 For an example see Lorin Hochstein's article on OOPS at Netflix