ST
можно не читать и идти в AWS на multi-az
Size: a a a
2021 March 16
a6
а вот если на авс упадёт метеорит (с)
ГХ
а вот если на авс упадёт метеорит (с)
у меня такая же фигня, только вместо aws у меня az
AD
а вот если на авс упадёт метеорит (с)
если упадет такой метеорит чтобы вынести все AZ то вам будет уже не до онлайн-сервисов
a6
у меня всё своё, как же хорошо, осспд
NK
Для того у кого небыло плана на случай пожара в OVH
https://telegra.ph/Kak-napisat-avarijnyj-plan-03-15
https://telegra.ph/Kak-napisat-avarijnyj-plan-03-15
Неплохо!
D
@nachalnikceha here it is.
User commands:
-
-
-
-
-
-
-
-
-
-
-
-
-
User commands:
-
/man - send list of commands to chat-
/coc - send code of conduct to user-
/jobs - send rules of publishing job opportunities and cv-
/ad - send rules of publishing advertising-
/chats - send list of friendly chats-
/events - send list of events to user-
/starter - send starter kit to user-
/middle - send middle kit to user-
/tasks - send user pack of DevOps tasks-
/course - send to user list list of courses-
/cert - send user list of certification tips & tricks-
/relocate - send user list of relocate chats and channels-
/report - forward replied message to admin chat and send link of replied message for fast-navigationD
Report on spam message was send to admins. Please be patient.
a6
это наработанные годами заметки от бывалых людей, только там ещё нужно бы добавить: планы могут быть разными в зависимости от ущерба (ущерб считается в бабле помноженным на процент затронутых аварией клиентов) т.е. - например отвалился филал и там никто ничего не может сделать (отравились новичком или шавухой всем филалом после корпоратива, или филиал вязл штурмом СОБР и.т.д) - это допустим 10% клиентов * на колво выхлопа от них * на колво человекочасов (Обычный план). Если допустим умер неткор и нет сети вообще не где - эт 90% процентов клиентов и т.д (Другой план)
NK
это наработанные годами заметки от бывалых людей, только там ещё нужно бы добавить: планы могут быть разными в зависимости от ущерба (ущерб считается в бабле помноженным на процент затронутых аварией клиентов) т.е. - например отвалился филал и там никто ничего не может сделать (отравились новичком или шавухой всем филалом после корпоратива, или филиал вязл штурмом СОБР и.т.д) - это допустим 10% клиентов * на колво выхлопа от них * на колво человекочасов (Обычный план). Если допустим умер неткор и нет сети вообще не где - эт 90% процентов клиентов и т.д (Другой план)
Я бы ещё добавил:
- failback plan когда кончается печальный эвент
- verification steps (infra/service).
- failback plan когда кончается печальный эвент
- verification steps (infra/service).
a6
у меня всё просто - если одному дц пинцет - во второй, если второму - третий, и т.д, все сразу они отказать могут только в случае мисконфига или атомного удара разнопланового (мисконфиги рулятся по-TADу - всегда есть резервный слой сетевого меша который поднимается в случае неработы первого и его дублирует 1=1), в принципе все может жить и без никчнёмных людишек если не трогать.
A
Всем привет.
Вопрос для тех, кто плотно работает с EKS:
Как можно организовать что-то подобное PodTolerationRestriction (https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#podtolerationrestriction)
Т.е. чтобы tolerations можно было прописывать только в определённых namespace'ах (например в kube-system и devops), а в других было бы невозможно без добавления в некий белый список?
Думаю про написание Dynamic Admission Controller, но чего-то более менее готового не нашёл и хочется проще :)
Может подскажете как ещё это можно организовать в EKS?
Вопрос для тех, кто плотно работает с EKS:
Как можно организовать что-то подобное PodTolerationRestriction (https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#podtolerationrestriction)
Т.е. чтобы tolerations можно было прописывать только в определённых namespace'ах (например в kube-system и devops), а в других было бы невозможно без добавления в некий белый список?
Думаю про написание Dynamic Admission Controller, но чего-то более менее готового не нашёл и хочется проще :)
Может подскажете как ещё это можно организовать в EKS?
A
Аналогичный вопрос про https://kubernetes.io/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default
Как такого добиться в EKS?
Т.е. чтобы, например, priorityclassname "system-critical" можно было использовать только в определённом namespace, например kube-system, а в других нет.
Как такого добиться в EKS?
Т.е. чтобы, например, priorityclassname "system-critical" можно было использовать только в определённом namespace, например kube-system, а в других нет.
Hn
a6
readonly file system
a6
a6
(sudo mount -o remount,rw / && gitalb-ctl restart )
VS
обычно это сигнал, что диску вот вот пердец настанет)
a6
обычно в ридонли хард уходит потому что его через жопу остановили, если это вм - то через жопу крашнулась