Size: a a a

DevOps — русскоговорящее сообщество

2021 April 30

ДС

Дмитрий Синявский... in DevOps — русскоговорящее сообщество
А Дежурный должен уметь разобраться в чужом коде, определить багу и сам исправить (если в силах)?
источник

U

Ugly in DevOps — русскоговорящее сообщество
смотря какой дежурный. если дежурит один из команды разработчиков - да, если это просто дежурный который смотрит в дашборды и эскалирует - нет
источник

AM

Alexander Morozov in DevOps — русскоговорящее сообщество
+1. Иначе это какой-то супермозг должен дежурить.
источник

U

Ugly in DevOps — русскоговорящее сообщество
да и опять же.. если один может починить багу сам без всех, без тестов и прочего
источник

U

Ugly in DevOps — русскоговорящее сообщество
нафига тогда остальные))
источник

U

Ugly in DevOps — русскоговорящее сообщество
обычно если дежурит кто-то из команды это значит что надо максимально быстро понять что именно сломалось, что бы вот как раз или починить самому, или сразу в нужного человека ткнуть эскалацией, а не по цепочке тыкаться
источник

AM

Alexander Morozov in DevOps — русскоговорящее сообщество
А еще есть шанс, что вместо ремонта он только усугубит проблему.
источник

U

Ugly in DevOps — русскоговорящее сообщество
вот вот.. подставит костыль, который решит текущую проблему, но где гарантии что остальное не разнесет с большими последствиями
источник

U

Ugly in DevOps — русскоговорящее сообщество
и опять же, если это прод, и все изменения только через джобы или прочую автоматику, надо давать ему права на всё. и у него должны тогда быть права доступа выше чем у всех команд. ибо надо везде
источник

AM

Alexander Morozov in DevOps — русскоговорящее сообщество
Поэтому (пункт №2). У дежурного должен быть разработанный заранее и при этом актуальный план восстановления сервисов и схема эскалации.
источник

U

Ugly in DevOps — русскоговорящее сообщество
причем не просто разработанный, а как минимум несколько раз "проверенный"
источник

U

Ugly in DevOps — русскоговорящее сообщество
а то как те бэкапы, которые никто не проверят))
источник

U

Ugly in DevOps — русскоговорящее сообщество
они есть, и ок. а как восстановить - а бэкапы то битые снимаются
источник

AM

Alexander Morozov in DevOps — русскоговорящее сообщество
Про полномочия тоже очень важный пункт, пусть будет пункт №3.
источник

AM

Alexander Morozov in DevOps — русскоговорящее сообщество
P.S. Можете вот эту книжку поискать и почитать. Тема дежурства великолепно раскрыта на конкретных примерах.
источник

DK

Dmitrij Kravchenko in DevOps — русскоговорящее сообщество
Привет всем. Ребята, нужна помощь, разрулил я значит на стороне бэка и фронта работу с двумя доменами, теперь нужна донастройка на стороне nginx. В чем задача: "2 домена - 1 сайт", если это всё без SSL, то в одном файле настроек прописал server_name и все завелось и работает. Для того, чтоб добавить SSL я разделил настройки каждого домена в отдельный файл, и получается что один домен теперь работает, а второй домен постоянно редиректит сам на себя же "ERR_TOO_MANY_REDIRECTS". Что нужно добавить в настройках, чтоб этот циклический редирект не происходил? (я не девопс, потому буду признателен если объясните на пальцах или дадите какой-то мануал) спасибо.
источник

AK

Andrey Kartashov in DevOps — русскоговорящее сообщество
разберись, где у тебя редирект возникает и почему
источник

DK

Dmitrij Kravchenko in DevOps — русскоговорящее сообщество
так в том и дело, что не могу понять, я делаю только 1 редирект с http на https, а где зацикленность происходит, пока не могу понять
источник

AK

Andrey Kartashov in DevOps — русскоговорящее сообщество
где ты делаешь редирект и при каком условии?
источник

DK

Dmitrij Kravchenko in DevOps — русскоговорящее сообщество
server {
   listen 80;
   
   server_name site.com www.site.com;

   return 301 https://$host$request_uri;
}
источник