These are chat archives for DevZenRu/live

18th
May 2019
Ghost
@ghost~5379e70c048862e761fa1e5e
May 18 19:37
:hand:
Nick Linker
@nlinker
May 18 19:37
Хэллов!
Sergey Prokshin
@rdist28_twitter
May 18 19:38
да
Nick Linker
@nlinker
May 18 19:38
Йоу-йоу
DevZen Bot
@devzenbot
May 18 19:49
Reliability Zen: Как измерить надежность, и как ее достигать.
Ghost
@ghost~5379e70c048862e761fa1e5e
May 18 19:57
SLA и прочие reliability как realtime - смысл не в отсутствии проблем, а в их предсказуемости
Ghost
@ghost~5379e70c048862e761fa1e5e
May 18 20:10
кардиостимулятор иногда останавливается, чтобы пациенты не привыкали
разработчики иногда уходят в отпуск, для профилактики bus factor
Valery Meleshkin
@sumerman
May 18 20:21
:joy:
Nick Linker
@nlinker
May 18 20:41
Получается, что порог вхождения огромен - пока не прочитаешь кучу документов (свои старые версии, и документы соседей, которых в случае гугла 100500)
manzur
@manzur
May 18 21:08
гость кажется путает symptom based с caused based alert/monitoring.
Ghost
@ghost~5379e70c048862e761fa1e5e
May 18 21:21
SRE crash-course :wink:
Ivan Glushkov
@gliush
May 18 21:22
кстати, даа!
Nevkontakte
@nevkontakte
May 18 21:28
@manzur возможны небольшие различия в интерпретации :) В моем понимании cause-based monitoring - явление мифическое. Если ты можешь автоматически установить причину (cause) падения сервиса, то скорее всего ты можешь автоматически ее митигировать и падения не будет. А если ты не знаешь, какой из сигналов является реальной причиной, то это просто симптом :)
Ну или я в терминологии не шарю, такое тоже может быть.
Ghost
@ghost~5379e70c048862e761fa1e5e
May 18 21:32
DevZen Bot
@devzenbot
May 18 21:32
Билеты на конференцию fpure.event
Из тем слушателей: "Literature Review: Distributed Teams"
https://www.lesswrong.com/posts/f2GF3q6fgyx8TqZcn/literature-review-distributed-teams
Nevkontakte
@nevkontakte
May 18 21:32
@nlinker про порог вхождения, сильно зависит от сложности сервиса, на самом деле. Даже чувак с 40 лет опыта в SRE может потратить уйму времени для разработки хорошего SLA для большого и сложного сервиса, а потом еще больше, чтобы убедить в этом всех заинтересованных.
manzur
@manzur
May 18 21:44
@nevkontakte ага, возможно дело в терминологии. я ориентируюсь по этой доке: http://files.catwell.info/misc/mirror/rob-ewaschuk-google-sre-philosophy-alerting.pdf
iliyaisd
@iliyaisd
May 18 21:47
Самая лучшая на моей практике коммуникация была в компании, в которой я когда-то начинал годы назад. Она принципиально нанимала только удалёнщиков среди технарей. С тех пор я всерьёз не воспринимаю, когда говорят насчёт необходимости личного присутствия.
Тогда мы висели на скайпе и тимвьювере
Это было отработано до автоматизма, у всех всё установлено и т.д.
Valery Meleshkin
@sumerman
May 18 21:51
интересно было бы про такой опыт послушать
Ghost
@ghost~5379e70c048862e761fa1e5e
May 18 21:53
а кто-то же так и делает. не то 37signals, не то stack overflow...
@nevkontakte подумайте о том, какие у вас есть основания считать, что всё пойдёт хорошо
Nevkontakte
@nevkontakte
May 18 21:54
Да!
Ghost
@ghost~5379e70c048862e761fa1e5e
May 18 21:55
в два раза больше изоленты
Valery Meleshkin
@sumerman
May 18 21:57
:joy: