Письма о предпринимаемых мерах операторами рассылались еще в октябре.
в ночь на 6.11 системы фильтрации включил Мегафон.
в ночь на 11.11 системы фильтрации включит ТЕЛЕ2
сейчас уже соотв-е оборудование тестирует МТС.
Нормальные компании СМС-шлюзы, как например 2кенгу.ру предупредили своих клиентов за 2 неделе до этих событий! информация предоставляется исчерпывающая!
да это не истерика. но признаюсь, я хотя человек уравновешенный по жизни — эта демагогия в комментариях меня изрядно выбешивает.
Моя статья о том, как взять и руками сделать реальное рабочее клевое решение, причем потратив на это 3 копейки и немного времени.
Если человек не умеет систематизировать мысли и привык шаманить — то получится как вы написали — зоопарк из скриптов, которые как работают не понятно. чтобы такого не было — вот вам алгоритм
я предложил алгоритмическое системное решение без 3-й ноды, которое позволяет избежать огромное количество головной боли по подъему резерва и восстановлению после крешей. Никакого зоопарка — надо просто взять и аккуратно сделать — совсем немного скриптов, все понятно как работает.
— за многолетний опыт работы в разных компаниях ( даже таких, где бюджет позволяет сделать грамотное «правильное» решение) я насмотрелся кучу историй когда админы читают лекции руководству надувают щеки, бросаются терминами и в итоге все упирается либо в
а) нежелание руководства инвестировать в закрытие аморфных рисков по безопасности (типа у нас все и так круто, а если сломается — пусть админы разбираются по факту)
б) тупо лень админов, отсутствие практики и / или организационную слабость
Это реально ВЕЗДЕ так! проектов с такими правильными решениями коих тут в коментах напредлагали наши гениальные IT-специалисты —
единицы!
и этот подходец тоже зашибись — типа если у организации нету лишних 5К евро на сервер то пусть она закрывается нафиг.
— эта статья не о том как правильно построить идеальный безотказный сервис, а о том как взять и сделать — закрыть риски, даже если на это нету бюджета.
Если ваши возможности (и организационные и финансовые) позволяют сделать все по-правильному — поздравляю, делайте эта статья просто не для вас. не надо лить кучи говна! я убежден, что огромному числу людей изложенный здесь алгоритм (вцелом как решение) будет очень полезен (при наличие воли к результату)
да какая разница на скольких серверах у нас приложения и СУБД? для описанного решения требуется минимум 2 машины и не требуется никакой балансир, циска и никакая другая железка которая может сама сломаться или отрезаться от мира — используется DNS сервер, за которым не надо ухаживать. решние можно построить с минимальными вложениями.
не хотите учиться — не учитесь — жуйте сопли своих правильных теорий. а 99% проектов в нете так и будут продолжать работать на дерьме
плюс описанного решения в том, что не требуется никакого кластера, не требуется третей машины для диагностики.
Все можно собрать на 2-х VPS'ках ценой по 3000 рублей в месяц каждая.
И это решение закрывает 90% потребностей большинства интернет проектов малого и среднего размера.
Можно сколько угодно филосовствовать на тему правильного отказоустойчивого решения, а можно взять и сделать то что тут написано. По моему обширному опыту — в большинстве проектов все заканчивается болтовней типа той, что здесь в комментах
это не российская культура — это комплекс неполноценности компенсируемый попытками самоутвердиться (причем словами а не делом) — последствия рабской психологии — комуняки во всем виноваты (
аварии в ДЦ это не 0,2% — это основное от чего мы стараемся защититься, чтобы не рвать себе ж… пу от беспомощности когда звонит клиент и говорит А ГДЕ СЕРВИС?
в теории все красиво — на практике у всех одно и тоже все. Пропадает сервер — телефон ДЦ недоступен из-за обилия звонков. Клиентам приходится отвечать «мы делаем все возможное» и никаких прогнозов по восстановлению!
100 раз это проходили!
описанное решение позволяет всегда сказать клиенту в случае чего: через 10 минут, сервис будет доступен. и все.
это реальное решение а не долбанное теоретизирование…
не надо воздух языком (пальцами..) молоть просто так — ни к чему.
на счет кеширования DNS — проблем никаких нету — пускай кешируются, второй IP тоже наш и на нем прокси. Вся штука нужна для оперативного переброса основного трафика на резервный сервак быстро и «само» во время аварии. и за дешево.
А от чего прибыль зависит линейно или нелинейно — это позвольте считать тем, кто нанимает сисадминов. Оставьте смсадминские понты при себе — как правило намного больше самомения у сисадминов чем реальных стоящих решений.
«Все это прекрасно делается» — расскажите как — добавим в копилку знаний. фигли щеки то надувать просто так…
У меня есть интересное наблюдение. Если программист спрашивает как чтото сделать на заграничном форуме — ему стараются ответить ровно на его вопрос, даже если он на чей то взгляд глупый. На наших же пост-советских форумах вместо ответа с вероятностью 90% задающего вопрос будут по максимуму лажать, доказывая, что он не специалист и не разбирается в предметной области — вместо ответа. Это какой то комплекс постсоветский.
вот и сейчас — к чему ваш коммент? я поставил задачу и предложил решение. Я знаю, что это решение реально является ноу хау — мало кто так делает, большинство не делают вообще ничего.
Какая вам разница как я озаглавил статью? Да, очевидно, что 24х7 не бывает в принице. Или бывает? ну предложите решение сами как это сделать. да еще в аналогичных бюджетах
2 мастера в нашей схеме не может быть никак. Как только один севрер стал мастером — он сам прописал свой IP на DNS в момент переключения из slave — все начиная с этого момента 2-й «мастер» увидит в DNS что он не мастер больше. А slave себя назначит мастером только если старый мастер не пишет в DNS.
моя статейка не об SLA а о том как малыми силами сделать максимально надежный сервис.
Есть компании разного уровня с разными бюджетом на технику. Если вы хотите за маленькие деньги дать чуть лучший результат чем все ваши ближайшие конкуренты с аналогичным уровнем инвестиций — тогда мое решение для вас.
Для любителей точных определений, сисадминов, деятелей науки и недооцененных гениальных инженеров.
Друзья, эта статья не является определением термина «откзаустойчивость», «24х7» и п т.п. И не является панацеей от всех бед.
Эта статья в основном предназначена для менеджеров по оптимизации инфраструктуры, фин. директоров, ИТ-директоров, тех, что считает деньги в проекте!
Это статься о том, как силами обычных доступных на рынке админов и программистов с использованием дешевого железа организовать устойчивый надежный сервис и при этом не трезвонить подчиненным техникам по ночам в случае аварии.
в кенгуру можно выбрать по какому тарифу работать — по дешевому с цифровым отправителем или по дорогому (но не 60коп) с подменой имени
Единственное кто пострадает — это клиенты банков, у кого СМС-сервис станет дороже.
Письма о предпринимаемых мерах операторами рассылались еще в октябре.
в ночь на 6.11 системы фильтрации включил Мегафон.
в ночь на 11.11 системы фильтрации включит ТЕЛЕ2
сейчас уже соотв-е оборудование тестирует МТС.
Нормальные компании СМС-шлюзы, как например 2кенгу.ру предупредили своих клиентов за 2 неделе до этих событий! информация предоставляется исчерпывающая!
Моя статья о том, как взять и руками сделать реальное рабочее клевое решение, причем потратив на это 3 копейки и немного времени.
Если человек не умеет систематизировать мысли и привык шаманить — то получится как вы написали — зоопарк из скриптов, которые как работают не понятно. чтобы такого не было — вот вам алгоритм
я предложил алгоритмическое системное решение без 3-й ноды, которое позволяет избежать огромное количество головной боли по подъему резерва и восстановлению после крешей. Никакого зоопарка — надо просто взять и аккуратно сделать — совсем немного скриптов, все понятно как работает.
— за многолетний опыт работы в разных компаниях ( даже таких, где бюджет позволяет сделать грамотное «правильное» решение) я насмотрелся кучу историй когда админы читают лекции руководству надувают щеки, бросаются терминами и в итоге все упирается либо в
а) нежелание руководства инвестировать в закрытие аморфных рисков по безопасности (типа у нас все и так круто, а если сломается — пусть админы разбираются по факту)
б) тупо лень админов, отсутствие практики и / или организационную слабость
Это реально ВЕЗДЕ так! проектов с такими правильными решениями коих тут в коментах напредлагали наши гениальные IT-специалисты —
единицы!
и этот подходец тоже зашибись — типа если у организации нету лишних 5К евро на сервер то пусть она закрывается нафиг.
— эта статья не о том как правильно построить идеальный безотказный сервис, а о том как взять и сделать — закрыть риски, даже если на это нету бюджета.
Если ваши возможности (и организационные и финансовые) позволяют сделать все по-правильному — поздравляю, делайте эта статья просто не для вас. не надо лить кучи говна! я убежден, что огромному числу людей изложенный здесь алгоритм (вцелом как решение) будет очень полезен (при наличие воли к результату)
не хотите учиться — не учитесь — жуйте сопли своих правильных теорий. а 99% проектов в нете так и будут продолжать работать на дерьме
Все можно собрать на 2-х VPS'ках ценой по 3000 рублей в месяц каждая.
И это решение закрывает 90% потребностей большинства интернет проектов малого и среднего размера.
Можно сколько угодно филосовствовать на тему правильного отказоустойчивого решения, а можно взять и сделать то что тут написано. По моему обширному опыту — в большинстве проектов все заканчивается болтовней типа той, что здесь в комментах
в теории все красиво — на практике у всех одно и тоже все. Пропадает сервер — телефон ДЦ недоступен из-за обилия звонков. Клиентам приходится отвечать «мы делаем все возможное» и никаких прогнозов по восстановлению!
100 раз это проходили!
описанное решение позволяет всегда сказать клиенту в случае чего: через 10 минут, сервис будет доступен. и все.
это реальное решение а не долбанное теоретизирование…
на счет кеширования DNS — проблем никаких нету — пускай кешируются, второй IP тоже наш и на нем прокси. Вся штука нужна для оперативного переброса основного трафика на резервный сервак быстро и «само» во время аварии. и за дешево.
А от чего прибыль зависит линейно или нелинейно — это позвольте считать тем, кто нанимает сисадминов. Оставьте смсадминские понты при себе — как правило намного больше самомения у сисадминов чем реальных стоящих решений.
«Все это прекрасно делается» — расскажите как — добавим в копилку знаний. фигли щеки то надувать просто так…
вот и сейчас — к чему ваш коммент? я поставил задачу и предложил решение. Я знаю, что это решение реально является ноу хау — мало кто так делает, большинство не делают вообще ничего.
Какая вам разница как я озаглавил статью? Да, очевидно, что 24х7 не бывает в принице. Или бывает? ну предложите решение сами как это сделать. да еще в аналогичных бюджетах
Есть компании разного уровня с разными бюджетом на технику. Если вы хотите за маленькие деньги дать чуть лучший результат чем все ваши ближайшие конкуренты с аналогичным уровнем инвестиций — тогда мое решение для вас.
Друзья, эта статья не является определением термина «откзаустойчивость», «24х7» и п т.п. И не является панацеей от всех бед.
Эта статья в основном предназначена для менеджеров по оптимизации инфраструктуры, фин. директоров, ИТ-директоров, тех, что считает деньги в проекте!
Это статься о том, как силами обычных доступных на рынке админов и программистов с использованием дешевого железа организовать устойчивый надежный сервис и при этом не трезвонить подчиненным техникам по ночам в случае аварии.