На щастя, оскільки інженерія надійності сайтів розвивалася внутрішньо в Google і лише нещодавно почала пробиватися до широкої спільноти, вона досить чітко визначена. Однак, це не веб-операції (або "системне адміністрування" - як приклад недостатньої ясності ви використовуєте обидва у своєму запитанні). Важко обговорити відмінності між двома речами, коли ти зовсім не впевнений, що таке одна з них.
Але я пригодний хлопець, тож я дам йому зняти.
У дуже традиційних магазинах розробники та сисадміни дуже сидять один від одного. Розробники створюють додаток, а потім вважають їх роботу закінченою, як тільки код буде здійснено. Sysadmins приймають артефакти збирання (який може бути просто кодом, якщо це інтерпретована мова) і розгортають його на виробничих серверах. Завданням sysadmins є підтримка роботи програми та в цілому керування виробничим середовищем. Однак часто проблеми з роботою пов'язані з проблемами архітектури в додатку; у sysadmins немає знань з програмування, щоб знати, що робить додаток, і розробники не знають, як додаток діє у виробничій топології з виробничим трафіком, тому ніхто не оснащений самим для вирішення проблеми.
Крім того, розробники, як правило, судять про те, наскільки швидко вони можуть виробляти нові функції, тоді як системні адміністратори судять про те, як нечасто перерви в програмі у виробництві. Оскільки зміни є однією з провідних причин поломки, це ставить протиріччя двох відділів - старе суперництво, яке шкодить бізнесу та людям, які займаються цим.
У якийсь момент деякі компанії, орієнтовані на розробників, настільки роздратувалися з цього приводу, що вони почали практикувати "NoOps" - вони ліквідували свої відділи операцій та сприйняті дорожні блоки, які прийшли разом із ними. Насправді це означало, що розробники брали на себе операційні ролі, але зберігали свої старі назви.
У дискусії навколо NoOps Джон Allspaw, тодішній віце-президент з технічних операцій у Etsy та редактор відомої книги веб-операцій , визначав ролі в Etsy таким чином:
Etsy Operations відповідає за:
- Відповідаючи на перебої, приймає дзвінок
- Системи оповіщення порогове значення, проектування
- Дизайн та огляд архітектури
- Створення колекції показників
- Конфігурація програми
- Розробка / управління інфраструктурою
Etsy Development відповідає за:
- Відповідаючи на перебої, приймає дзвінок
- Системи оповіщення порогове значення, проектування
- Дизайн та огляд архітектури
- Створення колекції показників
- Конфігурація програми
- Доставка громадського коду
Жоден із цих списків не є вичерпним, я впевнений, що мені чогось там не вистачає. У той час як Etsy Ops вніс зміни в додаток до виробництва, їх мало, але реально (а іноді й досить глибоко). Поки Етсі Дев робить зміни шеф-кухаря, їх мало, але реально. Якщо в обов'язках так багато дублювань, чому ви можете попросити різницю? Експертиза та домен. Не багато розробників глибоко знають, як працює TCP повільний старт, але Ops це робить. Не багато операторів мають всебічні знання алгоритмів сортування чи відповідності, але Dev робить. Ops має багаторічний досвід швидкого прогнозування використання ресурсів з прийнятною точністю, Dev цього не робить. Dev може не знати про плюси і мінуси розподілу параметрів навантаження на всі шари1-7, можливо, лише на 7, робить Ops. Моделювання відносин між особистістю може бути природним для розробника, воно може не спричинити. Зрештою, вони обидва виявляють рішення для різних форм візантійських сценаріїв невдач та зразків стійкості на всіх рівнях та рівнях.
У його світі розробники та інженери-оператори мали дуже схожі набори та обов'язки на високому рівні; там, де вони відрізнялися, була їхня експертиза. Їх різні спеціальності спонукали їх до спільної роботи над вирішенням проблем, а їхні спільні навички базового рівня дали їм мову для цього.
Це, як правило, визначення веб-операцій, на які я користуюся в більшості випадків. Так що ми будемо продовжувати разом.
Отже, що таке інженерія надійності сайту?
Книга Google SRE відкривається з визначенням SRE ..., а потім ще одна ..., а потім проводить розділ, продовжуючи визначати роль та цілу книгу, що висвітлює специфіку. Навіть коли розробляється в одній організації, здається, що важко звести роботу до одного єдиного узгодженого визначення.
Для початку нам потрібно повернутися до 2003 року, коли Бен Трейнор приєднався до Google і заснував першу команду інженерів з надійності сайту. Нагадаємо, що кілька пунктів тому ми були на початку 2010-х; але в 2003 році галузь все ще була досить сильно настроєна на поділ системи / розробника як на природний шлях. Тож, коли Бен каже, що СРЕ було б, що трапилося б, якщо інженер-програміст створив операційну команду, це було набагато радикальнішим способом з’єднання двох світів, ніж це зараз з'являється.
Визначення, подане в передмові, підкреслює кожне з трьох слів окремо:
- Техніка - використання інформатики та інженерних концепцій для вирішення проблем
- Надійність - орієнтація на те, щоб зробити системи більш масштабованими, надійнішими та ефективнішими
- Сервіс - пізніша еволюція "сайту", підкреслюючи, що СРЕ відповідають за мережеві послуги
У вступному розділі перераховані принципи інженерії надійності сайту:
- Забезпечення міцної уваги до інженерії - вжиття попереджувальних заходів, щоб уникнути частих сторінок та інших "трудів"
- Переконання в максимальній швидкості зміни, не порушуючи SLO послуги - предмет, який може легко мати власну відповідь на кілька сотень слів, але приблизно викладений як допомога розробникам вносити зміни, якщо вони не викликають занадто багато проблем
- Моніторинг - автоматичне оповіщення, коли справи йдуть не так
- Реагування на надзвичайні ситуації - виправлення речей, коли вони зламані
- Управління змінами
- Планування потенціалу
- Забезпечення
- Ефективність та ефективність - забезпечення того, що послуга працює на очікуваному рівні - вузькі місця шкодять користувачам, але надмірна потужність коштує грошей
Я б класифікував Інженерія надійності сайту як спеціалізований підмножина сучасних веб-операцій. Організація SRE орієнтується на автоматизацію всього , настільки економічно вигідною лише у досить великих компаніях. Такі ідеї, як бюджети на помилки, можуть працювати лише тоді, коли у вашій службі є багато, багато запитів, оскільки в іншому випадку ви втрачаєте деталізацію (для меншої послуги певна помилка може впливати на 0-20% ваших запитів, залежно від хвилини). Пов’язані сфери, такі як безпека, відсутні у визначенні SRE, оскільки компанії, достатньо великі для створення справжніх команд SRE, мають спеціальні команди з безпеки.
Програма SRE, визначена Google, - це веб-програми, розроблені для конкретних потреб Google, і не обов'язково застосовуються в інших місцях.
Однак, Інженерія надійності сайтів останнім часом розширюється в широкому використанні в галузі. Моя поточна назва роботи - SRE, хоча я працюю в набагато меншій компанії, і моя посадова інструкція досить добре відповідає визначенню веб-огляду Etsy від John Allspaw 2012 Etsy. Моя теорія полягає в тому, що ми просуваємося через заголовки як скорочення, щоб підтримувати еволюцію єдиного поля:
- Ми почали як сисадміни .
- Потім, оскільки веб-сайти стали більше "річчю", публікації вакансій почали посилатися на інженерів з веб-операцій, щоб відрізнити сисадмінів, які спеціалізувалися в Інтернеті, від тих, хто також займався ІТ загального офісу.
- Тоді DevOps повинен був відокремити тих, хто зручно користувався програмуванням, щоб зменшити завантаженість своїх веб-операцій.
- Але оскільки DevOps заплутався через відсутність чіткого визначення , ми прийняли інженерію надійності сайтів, щоб уточнити, що ми шукаємо людей, які працюють за викликом, які підтримують виробничі послуги.
Тож у чому різниця між систематиком та SRE? Рік, в якому вони отримали свою назву. Чим відрізняються традиційні операції від інженерії надійності сайту? SRE - це лише поточне втілення ops, використання нових інструментів (привіт, контейнери!), І оскільки мережеві програми продовжують ставати все більш масштабними та важливими, посилення уваги до практик, що дозволяють одному інженеру робити більше .