Comments 14
Действительно, очень выдуманная история.
В реальной жизни письмо было бы таким:
В реальной жизни письмо было бы таким:
«Алексей, я рассмотрел твои предложения и сделал вывод, что на текущем месте работы ты работаешь неэффективно и компания вынуждена распрощаться с тобой. Передай все дела в течении двух недель новому сотруднику, по совместительству моему племяннику.».
Ну это достаточно утрированное произведение и в реальной жизни, вряд ли было бы так просто и быстро.
Но в целом, у меня в практике, да и у коллег, были кейсы где подобного рода предложения помогали развитию компании и карьерному росту:)
В случае, если компания — госконтора, то да.
А в нормальном, ориентированном на доходы, бизнесе я за 8 мест работы никогда «кумовства» не встречал. Если где-то руководители и приводили своих людей, то проверенных спецов с прошлых работ и претензий к ним не было.
А в нормальном, ориентированном на доходы, бизнесе я за 8 мест работы никогда «кумовства» не встречал. Если где-то руководители и приводили своих людей, то проверенных спецов с прошлых работ и претензий к ним не было.
UFO just landed and posted this here
Не совсем так, у мобильной сети и у мобильного телефона меньше девяток и если повысить стабильность приложения с 99 на 99.9999% то пользователь скорее всего не заметит разницы, потому что мобильная и сам телефон работают не так стабильно.
UFO just landed and posted this here
Насовсем так.
1. Смотрите, у вас есть микросервис А который зависит от 10 других. Допустим один из десяти является обязательным для микросервиса A и называется микросервис В. Так вот, если есть проблемы у микросервиса B, то это отразится и в показателях доступности микросервиса А, так как запросы к нему будут заканчиваться с ошибкой.
2. Зачастую строют графики не только по конкретным микросервисам, но и по проекту в целом.
3. При анализе работы используют еще и бизнесметрики. Например это может быть количество регистраций, количество бронирований или заказов.
4. Так же, за частую используют метрики полученные напрямую от устройства клиентов.
Приведенный вами пример, с математической точки зрения, верный и в целом не решен смысла. Но все не так линейно. И sli/slo это один из инструментов и на мой взгляд сильно переоцененный и работает он только в комплексе с большим количеством других инструментов и практик.
1. Смотрите, у вас есть микросервис А который зависит от 10 других. Допустим один из десяти является обязательным для микросервиса A и называется микросервис В. Так вот, если есть проблемы у микросервиса B, то это отразится и в показателях доступности микросервиса А, так как запросы к нему будут заканчиваться с ошибкой.
2. Зачастую строют графики не только по конкретным микросервисам, но и по проекту в целом.
3. При анализе работы используют еще и бизнесметрики. Например это может быть количество регистраций, количество бронирований или заказов.
4. Так же, за частую используют метрики полученные напрямую от устройства клиентов.
Приведенный вами пример, с математической точки зрения, верный и в целом не решен смысла. Но все не так линейно. И sli/slo это один из инструментов и на мой взгляд сильно переоцененный и работает он только в комплексе с большим количеством других инструментов и практик.
UFO just landed and posted this here
Примеры SLA: сервис доступен 99,95% времени в течение года; 99 критических тикетов техподдержки будет закрыто в течение трёх часов за квартал; 85% запросов получат ответы в течение 1,5 секунд каждый месяц.
Это все же примеры SLO, а не SLA. Примером SLA было бы кто кому и сколько платит за нарушение вышеуказанных метрик.
Позвольте не согласиться.
« Соглаше́ние об у́ровне предоставле́ния услу́ги (англ. Service Level Agreement, SLA) — термин методологии ITIL, обозначающий формальный договор между заказчиком (в рекомендациях ITIL заказчик и потребитель — разные понятия) услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги.»
Тут важно: согласованный уровень обслуживания. А санкции за не предоставления могут быть, а могут и не быть.
Если очень просто: SLA это договор с заказчиком, SLO ,SLI это внутренний договор. Как правило SLO и SLI более строгие, по отношению к SLA.
Использование методологии ITIL в качестве первоисточника знаний о SRE, скажем так, несколько странный подход. Может быть лучше прочитать SRE Book? Там SLA вводится так:
И еще сноска, которая под номером 16:
Вы можете с этим не соглашаться, но тогда у вас в статье не SLA в понимании SRE, а что-то другое.
Agreements
Finally, SLAs are service level agreements: an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain. The consequences are most easily recognized when they are financial—a rebate or a penalty—but they can take other forms. An easy way to tell the difference between an SLO and an SLA is to ask «what happens if the SLOs aren’t met?»: if there is no explicit consequence, then you are almost certainly looking at an SLO.16
И еще сноска, которая под номером 16:
16Most people really mean SLO when they say «SLA.» One giveaway: if somebody talks about an «SLA violation,» they are almost always talking about a missed SLO. A real SLA violation might trigger a court case for breach of contract.
Вы можете с этим не соглашаться, но тогда у вас в статье не SLA в понимании SRE, а что-то другое.
Использование методологии ITIL в качестве первоисточника знаний о SRE, скажем так, несколько странный подход. Может быть лучше прочитать SRE Book? Там SLA вводится так:
Понятие SLA появилось задолго до появления термина SRE и по этому давать определение не SRE вполне допустимо. Тем более, приведенное вам определение ни сколь не противоречит тому, что я привел.
SLA — это договор с внешними клиентами, который скорее всего предусматривает штрафные санкции.
SLO — это внутренний договор.
Ваша реализация SLA принципиально противоречит SRE.
Это нормально, и даже хорошо, когда методологии не следуют слепо, а адаптируют к реалиям. Очевидно, что для кого-то такой SLA нужен и полезен. Но если бы в статье была небольшая ремарка, что речь идет не о классическом SLA в понимании SRE, а о каком-то кастомном (или из другой методологии) решении, более подходящем к данному случаю — читающим было бы гораздо понятнее.
Я уже не в первый раз вижу/слышу такое понимание SLA (именно с точки зрения SRE), где речь идет о SLO для внешних клиентов. Сначала казалось, что люди просто не в теме. После еще нескольких повторов уже стало казаться, что это я что-то путаю. В этот раз я еще раз перечитал, что же написано в SRE. И SLA там все же про последствия и ответственность, а не про внешних клиентов.
Это нормально, и даже хорошо, когда методологии не следуют слепо, а адаптируют к реалиям. Очевидно, что для кого-то такой SLA нужен и полезен. Но если бы в статье была небольшая ремарка, что речь идет не о классическом SLA в понимании SRE, а о каком-то кастомном (или из другой методологии) решении, более подходящем к данному случаю — читающим было бы гораздо понятнее.
Я уже не в первый раз вижу/слышу такое понимание SLA (именно с точки зрения SRE), где речь идет о SLO для внешних клиентов. Сначала казалось, что люди просто не в теме. После еще нескольких повторов уже стало казаться, что это я что-то путаю. В этот раз я еще раз перечитал, что же написано в SRE. И SLA там все же про последствия и ответственность, а не про внешних клиентов.
Управление надежностью — это нифига не специфика IT. Вообще, абстрактно, это подраздел управления рисками. Потому что надежность показывает вероятность наступления негативного события. Вложение денег в надежность (например увеличение запаса прочности балки моста) уменьшает вероятность наступления негативного события (разрушения моста при перегрузе). Но в тоже время увеличивает себестоимость. Бизнес получает возможность учитывать надежность как понятный ему параметр — доля в себестоимости (в случае моста). Ну а имея возможность учета — появляется возможность управления.
IT компании следуют по уже проложенному пути — по мере роста прибыли, растет и ущерб в результате неожиданных сбоев. В начале источником неожиданных сбоев были разработчики выкатывающие изменения прямо на продакшн. Их изолировали от продакшна с помощью кьюэев. По мере роста сложности продуктов — скорость внедрения изменений упала ниже плинтуса. Разработчики задолбались бодаться с опсами и придумали сервисную, а потом и микросервисную архитектуры — и теперь целостность продукта стала попаболью опсов. Потому что продукт появляется не после сборки, а только после деплоймента. Так что SRE это еще одно подмножесто OPSов.
Ну а история Лехи — свежо предание, да верится с трудом. Дев сообщает опсу про проблемы с сервисом в продакшне? Рилли? Типа опсы совсем мух не ловят, а девы их дублируют? Дальше. Компания внедряла SDLC задрачивая девов и кьюэев единственно правильным процессом, чтобы предотвратить деплоймент непроверенного кода. Но пришел опс Леха и зафигачил самописный патч прямо на продакшн. Судя по всему он был очень плохим девом, если за 3,5 года так и не смог запомнить SDLC. Да и способ решения выглядит не самым оптимальным — может все таки стоило добавить обработку ошибок? А если сервис третьестепенный — так может в первостепенных сервисах стоит ослабить зависимость от него? Ну чтобы все не ломалось при недоступности третьестепенного сервиса?
По поводу доступности — для многопользовательских систем имеет значение не сбой для одного конкретного пользователя, а количество пользователей страдающих от сбоя в произвольный момент времени. Потому что часть пользователей обратится в поддержку. А это прямые расходы. И с ростом пользовательской базы — растут и расходы на их поддержку. И иногда переход от 99,99% к 99,999% означает уменьшение колл центра с 1000 операторов до 100. Что дает обоснование с точки зрения ROI.
IT компании следуют по уже проложенному пути — по мере роста прибыли, растет и ущерб в результате неожиданных сбоев. В начале источником неожиданных сбоев были разработчики выкатывающие изменения прямо на продакшн. Их изолировали от продакшна с помощью кьюэев. По мере роста сложности продуктов — скорость внедрения изменений упала ниже плинтуса. Разработчики задолбались бодаться с опсами и придумали сервисную, а потом и микросервисную архитектуры — и теперь целостность продукта стала попаболью опсов. Потому что продукт появляется не после сборки, а только после деплоймента. Так что SRE это еще одно подмножесто OPSов.
Ну а история Лехи — свежо предание, да верится с трудом. Дев сообщает опсу про проблемы с сервисом в продакшне? Рилли? Типа опсы совсем мух не ловят, а девы их дублируют? Дальше. Компания внедряла SDLC задрачивая девов и кьюэев единственно правильным процессом, чтобы предотвратить деплоймент непроверенного кода. Но пришел опс Леха и зафигачил самописный патч прямо на продакшн. Судя по всему он был очень плохим девом, если за 3,5 года так и не смог запомнить SDLC. Да и способ решения выглядит не самым оптимальным — может все таки стоило добавить обработку ошибок? А если сервис третьестепенный — так может в первостепенных сервисах стоит ослабить зависимость от него? Ну чтобы все не ломалось при недоступности третьестепенного сервиса?
По поводу доступности — для многопользовательских систем имеет значение не сбой для одного конкретного пользователя, а количество пользователей страдающих от сбоя в произвольный момент времени. Потому что часть пользователей обратится в поддержку. А это прямые расходы. И с ростом пользовательской базы — растут и расходы на их поддержку. И иногда переход от 99,99% к 99,999% означает уменьшение колл центра с 1000 операторов до 100. Что дает обоснование с точки зрения ROI.
Sign up to leave a comment.
Как Лёха стал инженером по SRE: выдуманная история про невыдуманные проблемы