Pull to refresh

Comments 39

>модифицированный командный интерпретатор bash

зачем?
На тот момент мы использовали старую версию операционной системы openSUSE и, как следствие, старую версию bash «из коробки». Вместо того, чтобы обновить bash целиком, решили бэкпортировать необходимый функционал из новой версии. В процессе изменений была допущена ошибка.
На данный момент bash обновлён целиком.
Тот самый момент, когда проще портировать bash, чем bash-скрипты
Уточню, что забэкпортить необходимые изменения на тот момент выглядело проще, чем обновляться на новую ветку. В итоге мы всё равно обновились на новую ветку, что потребовало фиксить синтаксис некоторых системных и наших скриптов, но это уже другая история.
>В модифицированном нами коде bash
Как вы старательно раскладываете грабли…
Вот поэтому я и не люблю языки программирования, в которых синтаксис активно зависит от непечатаемых символов ( python и т.п. ).
Я на подобное нарвался с какой-то древней утилитой (возможно make или что-то совсем экзотическое) еще учась в ВУЗе, на какой-то лабораторной работе. Что-то работало совершенно не так только от того, что где-то стояла табуляция вместо пробела.
Итого, единственный правильный способ обработки непечатаемых символов (пробелов, табуляций, переносов строк и возвратов каретки) в программах — пропускать их идущие подряд в любом порядке и в любом количестве и считать это одним «виртуальным разделителем».
> python и т.п.

Просто не надо заставлять уборщицу вносить изменения в код. Для Python есть куча линтеров, PEP8 и прочее. При наличии адекватно настроенного редактора ошибиться с чем-то типа пробела или отступа невозможно. Специалисты это знают и умеют.
Позволю не согласиться. Везде, где присутствует ручная работа, возможны ошибки. Это аксиома.

Чем больше граблей разложено в системе, тем больше шанс получить по голове. Вероятность не наступить ни на одни грабли падает в геометрической прогрессии с ростом числа граблей и числа прохожих (сотрудников). Если один человек наступает на одни грабли с вероятностью 0.01% в год, то хотя бы один из 100 человек наступят хотя бы раз на одни из 100 граблей — 1-(0.9999^100)^100 = 63% (упс!)

Проблемы необходимо устранять системно — раз и навсегда, чтобы не оставлять ошибкам ни единого шанса.
> Это аксиома.

Я не про ошибку вообще, а конкретно про «синтаксис активно зависит от непечатаемых символов». При использовании правильно настроенного редактора это не проблема, т.к. всё выявляется автоматически. Поэтому и нужны стандарты кодирования.

Понятно, что когда уборщица садится фиксить фантазии велосипедиста, то получается некрасиво.
Надо чтобы было хорошо и при наличии правильно настроенного редактора, и при его отсутствии.
В жизни ведь всякое бывает, иногда и в «полевых условиях» приходится код править. Редакторы — их много, они разные (кому-то удобен один, кому-то другой), иногда проприетарные (т.е. любой так просто не скачаешь), иногда под разные ОС (и под нужную в данный момент может не оказаться), иногда они перестают поддерживаться и т.д. И код может переходить из рук в руки, из компании в компанию и т.д., а везде редакторы разные.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
В статье как-то ничего не сказано о дальнейшей судьбе дежурного администратора, как он такой стресс перенёс?
Все с ним было хорошо. По итогам аварии никто не был уволен — починили и сели разбираться с найденными проблемами и рисками.
никого не уволили? серьезно?

ну премию хоть кому-нибудь дали? хоть один достойный человек купил себе машину по результатам восстановления бизнеса?
Так вопрос не об увольнении, а о компенсации работодателем потери нервных клеток работником.

Оффтопик: даёшь классификацию профессии системного администратора как тяжелую/нервную с сокращённым сроком для выхода на пенсию; расширенным отпуском; обязательными командировками в санатории!
В модифицированном нами коде bash оказался другой баг, из-за которого интерпретатор при обнаружении пустой строки в конце конфигурационного файла входил в бесконечный цикл и переставал отвечать на внешние команды.
А зачем вообще трогать системный bash? #!/usr/local/super_bash/bin/bash прекрасно справляется с задачей установки подходящего интерпритатора для скрипта.

Да и невозможность штатного обновления выглядит странно. Для меня это звучит примерно так: «скрипты были написаны абы как, без соблюдения требований и стандартов».

И, кстати, очень хотелось бы взглянуть на пример кода, который заставлял отказываться от обновленных версий в пользу ручной модификации кода интерпритатора (для самообразования, что бы так не делать)
из статьи не понял, сможете ли вы сегодня произвести холодный запуск системы, появился ли кейс с периодическим перезапуском подсистем для избегания указанной проблемы с носителями и инициализацией?
Зависимости, мешающие холодному запуску — устранены. Новые и существующие системы тестируются на наличие подобной проблемы. Есть возможность проблемные системы отключать, на тот случай если в production всетаки попадет проблемный код. И это тоже тестируется. Тестирование перезапуском по питанию специально не проводим, но это иногда случается :)
Действуем по плану действий при аварии!
В одной известной мне компании, скрипты пишутся уже около 15-ти лет на /bin/sh. Проблем с несовместимостью не было ни разу. Баш — зло для скртиптинга в продакшне.
Разработчик, создававший и тестировавший шаблон

Но дежурный администратор правил файл шаблона в другом редакторе, который поместил этот символ в конец файла

То есть критично важный код пишут и тестируют одни и те же люди, а потом другие люди еще его правят? Блестяще организованный процесс обеспечения качества, есть чему поучиться.

Понятно почему у вас бажные скрипты выполняются в бажном кастомном интерпретаторе, а потом все валиться.

Потом, пункт два:
Одноклассники состоят из примерно 150 подсистем (различные базы данных, серверы бизнес-логики, кэши, графы, фронтэнды, системы конфигурации и т.д.). И работоспособность практически каждой подсистемы зависит от доступности других.

Вы считаете это хорошей архитектурой?

В извлечении уроков я не увидел ничего, касающегося пересмотра архитектурных подходов.

P.S. Избавьте от этих вопросов для самопроверки, в данной ситуации на двоешников похожи больше вы.
Расскажите же, какая должна быть архитектура.
Чем меньше точек отказа, тем лучше. Ваш, Кэп.

150 программных точек отказа — действительно очень много. Возможно, в статье имелось в виду другое.
Всё правильно: любому проекту хватит и трёх подсистем: nginx + PHP + MySQL.
Если серьёзно, под подсистемами имелись в виду модули со своей кодовой базой, своим кластером оборудования и своей конфигурацией.
150 подсистем — не значит 150 точек отказа. Наоборот: если ломается один модуль, он не ломает весь портал, а влияет лишь на небольшую часть функциональности.
Раньше это было не совсем так, о том в статье и речь, но после проделанной работы над ошибками подсистемы стали куда более независимыми в плане обслуживания.
Одноклассники состоят из примерно 150 подсистем (различные базы данных, серверы бизнес-логики, кэши, графы, фронтэнды, системы конфигурации и т.д.). И работоспособность практически каждой подсистемы зависит от доступности других.


Так 150 подсистем не означает 150 точек отказа всей системы. В идеальной системе все части должны быть не зависимы. В этом случае отказ одной из 150 частей не окажет влияния на остальные и пострадает небольшая часть функционала.

Можно иметь 1 большое хранилище данных и при его отказе из за бага потерять весь сайт, а можно иметь 50 и потерять 1/50.

При этом для обслуживания текущей нагрузки серверов будет примерно столько же, т.е. количество железных точек отказа будет одинаковое.

С другой стороны количество програмных точек отказа скорее связано с объёмом кода, сложностью задач, уровнем квалификации. И скорее всего багов в системе которая разделена на модули будет меньше, чем в одном большом.

В реальности конечно нельзя построить такую идеальную систему, где нет взаимосвязей, но к этому надо стремиться. Одноклассники как раз пытаются сделать так, что бы эффект от програмных и железных отказов был как можно более локализован.
Ждем постов про сегодняшний сбой! :)

А найдется перевод статьи на eng? Хотел отправить коллегам, а перевод не нашел.


Если нет, задумайтесь о переводе. Я уверен, каждой второй вашей статье обеспечено место в топе на hackernews :)

Перевода нет. Задумались. Спасибо!
На данный момент завершён переход на системы на базе Cassandra и Voldemort.

Как корабль назовёшь так он и поплывёт

Sign up to leave a comment.