По некоторым оценкам, Twitter потерял примерно 80% сотрудников. Каким бы ни было реальное число, в компании есть команды, в которых полностью пропали разработчики. Тем не менее, веб-сайт продолжает работать, а твиты продолжают публиковаться. Из-за этого многие задаются вопросом, что происходит со всеми этими разработчиками, и не был ли штат компании попросту раздут. Я бы хотел рассказать о собственном маленьком уголке в Twitter (впрочем, он был не таким уж и маленьким), а также о работе, которая выполнялась для того, чтобы система продолжала функционировать.
Краткая информация и история
В течение пяти лет я работал инженером по надёжности сервиса (Site Reliability Engineer, SRE) в Twitter. Из них четыре года я был единственным SRE в команде, занимавшейся кэшами. До меня было несколько человек, и ещё я работал с целой командой, в которую приходило и из которой уходило множество людей. Но в течение четырёх лет я единственный в команде отвечал за автоматизацию, надёжность и эксплуатацию. Я спроектировал и реализовал большинство инструментов, благодаря которым поддерживалась работа, поэтому мне кажется, я имею достаточную квалификацию, чтобы говорить об этом. (Наверно, подобным опытом обладают один-два человека)
Кэш может использоваться для ускорения работы или для снижения объёма запросов к подсистеме, работа которой обходится дороже. Если у вас есть сервер, ответ которого занимает 1 секунду, но каждый раз это один и тот же ответ, то вы можете сохранить этот ответ на кэш-сервер, где ответ может отправляться за миллисекунды. Или если у вас есть кластер серверов, на котором обработка 1000 запросов в секунду может стоить $1000, то вместо него можно использовать кэш для хранения запросов и их возврата с этого кэш-сервера. Тогда у вас получится кластер меньшего размера за $100 и большой и дешёвый кластер серверов для кэша ещё примерно за $100. (Приведённые числа — это лишь примеры для демонстрации принципа.)
Кэши получают большую часть трафика, который приходит на сайт. Твиты, все ленты пользователей, личные сообщения, реклама, аутентификация — всё это выдаётся из серверов команды, занимающейся кэшем. Если с кэшем возникнут проблемы, то вы как пользователь это сразу заметите.
Когда я присоединился к команде, моим первым проектом была замена старых машин на новые. Для этого не существовало ни инструментов, ни автоматизации, мне просто дали электронную таблицу с именами серверов. Могу с удовольствием сказать, что теперь работа в этой команде ведётся совершенно иначе!
Как поддерживается работа кэша
Первый важный пункт в поддержании работы кэшей заключается в том, что они выполняются, как задачи Aurora в Mesos. Aurora находит серверы для выполнения на них приложений, а Mesos агрегирует все серверы, чтобы Aurora знала о них. Также Aurora поддерживает работу приложений после их запуска. Допустим, если кластеру кэша нужно 100 серверов, то он сделает всё возможное, чтобы работали все 100. Если сервер по какой-то причине полностью ломается, Mesos обнаруживает это и удаляет сервер из агрегированного пула; благодаря этому Aurora будет знать, что работает только 99 кэшей и что ей нужно найти новый сервер из Aurora для запуска. Она автоматически находит сервер и общее количество снова становится равным 100. Вмешательство человека при этом не требуется.
В дата-центре серверы помещаются в так называемые стойки. Серверы в стойках подключаются к другим серверам в стойках при помощи серверного коммутатора. Далее идёт целая сложная система присоединений коммутаторов к другим коммутаторам и маршрутизаторам, в конечном итоге подключённая к Интернету. В стойке может содержаться примерно 20-30 серверов. У стойки может случиться неполадка, коммутатор может поломаться или у него перегорит блок питания, что приведёт к отключению всех 20 серверов. Ещё одно удобство Aurora и Mesos заключается в том, что они делают так, чтобы в одну стойку не помещалось слишком много приложений. Благодаря этому, если целая стойка внезапно отключится, Aurora и Mesos найдут новые серверы, которые станут новым домом для приложений, работавших в стойке.
В вышеупомянутой электронной таблице также отслеживалось количество серверов в стойках; составитель таблицы стремился к тому, чтобы их было не слишком много. Благодаря новым инструментам при вводе новых серверов в эксплуатацию мы можем всё это отслеживать автоматически. Эти инструменты гарантируют, что у команды не будет слишком много физических серверов в одной стойке и что всё распределено так, чтобы случайные сбои не вызывали проблем.
К сожалению, Mesos не выявляет сбои каждого из серверов, поэтому нам нужен дополнительный мониторинг аппаратных проблем. Мы отслеживаем такие аспекты, как дефектные диски и сбойная память. Некоторые из этих проблем не приводят к отказу всего сервера, но могут замедлить его работу. У нас есть дэшборд алертов, который сканируется на наличие поломанных серверов. Если обнаруживается, что один сервер сломан, мы автоматически создаём заявку на ремонт для сотрудника дата-центра, чтобы он решил проблему.
Ещё одно важное ПО, которое есть у команды — это сервис, отслеживающий период работоспособности (аптайм) кластеров кэша. Если в короткий период времени слишком большое количество серверов оказывается отключённым, то новые задачи, требующие удаления кэша, будут отклоняться, пока ситуация не окажется безопасной. Так мы защищаемся от внезапного отключения целых кластеров кэша и от чрезмерной нагрузки на сервисы, которыми мы их защищаем. У нас настроены ограничения на такие случаи, когда слишком много серверов быстро отключатся, слишком много находится одновременно в ремонте или когда Aurora не может найти новые серверы для размещения в них старых задач. Чтобы создать заявку на ремонт сервера, у которого выявлена поломка, мы сначала проверяем, безопасно ли удалять задачи из него, проверяя этот сервис; если он пуст, то создаётся пометка, что техник дата-центра может безопасно с ним работать. После того, как техник дата-центра пометит сервер как починенный, наши специальные инструменты, которые занимаются отслеживанием этого, автоматически активируют сервер, чтобы он мог выполнять задачи. Единственный человек, который при этом необходим — это тот, кто чинит сервер в дата-центре. (Интересно, действительно ли это по-прежнему люди?)
Также мы устранили повторяющиеся проблемы с приложениями. У нас возникали баги, когда новые кэш-серверы не добавлялись обратно в пул (состояние гонки при запуске) или когда для добавления обратно сервера требовалось до 10 минут (логика O(n^n)). Поскольку благодаря всей этой работе по автоматизации мы не утопали в ручной работе, нам удалось создать в команде культуру, позволяющую устранять подобные проблемы, не препятствуя выполнению проектов. У нас были и другие автоматические решения проблем, например, если происходил выброс каких-то метрик приложения (скажем, задержки), мы автоматически перезапускали задачу, чтобы заявка на устранение неполадки не поступала инженеру. Команда получала примерно по одной заявке в неделю, и почти никогда она не была критически важной. В смены дежурства у нас часто случалось так, что не было ни одной заявки.
Также одной из самых важных причин того, что сайт не «лёг», стало планирование мощностей. У Twitter работало два дата-центра, которые могли выдержать нагрузку при полном переносе на них работы целого сайта. Каждый важный работающий сервис мог выполняться из одного дата-центра. Суммарные доступные мощности в любой момент времени составляли 200%. Это было необходимо только для катастрофических сценариев, а в основную часть времени оба дата-центра обслуживали трафик. Дата-центры заняты максимум на 50%. На самом деле, на практике это даже можно считать высокой нагрузкой. При вычислении потребностей в мощностях определяется, что нужно для того, чтобы один дата-сервер обрабатывал весь трафик, а затем поверх этого обычно добавляется резерв! Если нагрузку не нужно аварийно переносить, то для дополнительного трафика есть большой резерв серверов. Авария целого дата-центра — довольно редкое событие, которое произошло за пять лет моей работы только один раз.
Кроме того, мы обеспечивали разделение кластеров кэша. У нас не было мультиарендных (multi tenant) кластеров, занимавшихся обработкой всего и имевших изолирование на уровне приложений. Благодаря этому при возникновении проблем у одного кластера «радиус поражения» накрывал только этот кластер и, может быть, несколько соседних серверов на той же машине. Этому способствует Aurora, обеспечивая распределение кэшей: проблема затрагивает малую часть устройств, а мониторинг со временем позволяет устранить неполадку.
Так чем же я там занимался?
Всем тем, что описал выше! А ещё я общался с клиентами (командами, использовавшими кэш в качестве сервиса). После того, как завершил автоматизацию, я автоматизировал дальше. Также я работал над интересными проблемами производительности, экспериментировал с технологиями, которые могли улучшить систему, и руководил несколькими крупными проектами по сокращению трат. Я выполнял планирование мощностей и определял, сколько серверов нужно заказать. Я не просто получал зарплату за то, что весь день играл в видеоигры и пил кофе, как может показаться.
Вот так мы поддерживали работоспособность кэшей, обслуживающих запросы к Twitter. Это лишь часть того, в чём заключалась повседневная работа. Чтобы достичь такого положения, требовалось много работы в течение долгих лет. И сейчас мы можем отдать должное тому, что вся система продолжает работать!
По крайней мере, пока — я уверен, что где-то внутри таятся баги…
Комментарии (65)
mixsture
23.11.2022 12:28+28логика O(n^n)
n квадрат может? n*n или n^2?
Ну просто текущая запись считывается как n в степени n и это очень много.
maeris
23.11.2022 19:45-6O(n^n) это факториал. Может, там разные порядки чего-то перебираются, кто их знает.
knstqq
23.11.2022 22:03+13нет, O(N!) <<< O(N^N) во много раз.
1*2*3*...*N <<< N * N * ... N
0xd34df00d
24.11.2022 03:39+5А вот и нет, не во много раз. Довольно известно приближение Стирлинга, где n! ~ sqrt(n) (n / e) ^ n.
larasage
24.11.2022 07:43+4для 10 разница почти в 3 тысячи раз, для 15 - более чем в 300 тысяч раз. Это не много?
Cerberuser
24.11.2022 08:08-1Для 10 разница чуть более чем в 2 раза (причём в пользу факториала), если верить Wolfram Alpha. Предел отношения (если верить ей же) - 1/sqrt(2*pi). Учитывая, что сами значения уже для 10 имеют порядок 10^6 - это много?
gdsmiler
24.11.2022 09:48+5Чето вы не то ввели в Wolfram Alpha, комментатор до этого прав 10^10 больше 10! примерно в 3000 раз
Cerberuser
24.11.2022 09:50Но ответ-то комментатора выше был на слова про приближение Стирлинга, которое отличается как раз в 2 с небольшим раза.
gdsmiler
24.11.2022 10:32+3Возможно я туплю, но мне ветка выглядела как обсуждение разницы между O(N^N) и O(N!)
larasage
24.11.2022 10:43Не знаю, что там насчитал Wolfram Alpha, по приведенной формуле (Стирлинга) посчитал в Calc - опять получил разницу в 2776 раз
0xd34df00d
24.11.2022 20:05+1На фоне самих чисел — немного, и считать по первым нескольким членам последовательности асимптотику — не очень хорошая идея. Например, относительная разница логарифмов вообще убывает.
Cerberuser
24.11.2022 08:10+3Строго говоря, вы говорите чуть-чуть о разных вещах - n^n всё-таки сильно больше, чем (n/e)^n (второе - o(первого)).
RAX7
24.11.2022 04:07Если при n=1 требуется 1ms времени для добавления сервера обратно в пул, то для n^n*1ms = 10min * 60 * 1000, n ≈ 6.08 (серверов в пуле). Если требуется 10ms, то n ≈ 5.24. Для 1000ms - 3.37. Это конечно очень много, но при малом количестве серверов в пуле это будет работать.
N-Cube
23.11.2022 12:57+34Столько слов, а по сути установлен Apache Mesos плюс ПО мониторинга и один человек за всем этим следил:
> я был единственным SRE в команде, занимавшейся кэшами. До меня было несколько человек, и ещё я работал с целой командой, в которую приходило и из которой уходило множество людей…
Так зачем все эти люди?
Я спроектировал и реализовал большинство инструментов, благодаря которой поддерживалась работа…
Серьезно, автор лично написал Apache Mesos? Или таки автор один раз установил готовое ПО и теперь называет это «проектирование и реализация»?
sunnybear
23.11.2022 13:43+18Там ещё куча скриптов и прочей логики, которые по алертам что то должны делать (нагрузку балансировать, кэш не очищать, синкать данные и т.д.). Но обычно после настройки всей этой логики (и без существенного развития системы) все работает как часы.
EmacsBrain
23.11.2022 14:21+14Все эти замечательные автоматизации выглядят простыми и самовосстанавливающимися кубиками внутри большой конструкции из подобных кубиков и пока поломки лежат в пределах алгоритмов самовосстановления, всё хорошо. Надёжность любой системы не выше надёжности самой ненадёжной её части и когда какой-нибудь кубик перестанет справляться с самовосстановлением простота конструкции испаряется. Мониторинги до какого-то момента смогут указывать на проблемные компоненты, но мало понять на что именно указывает мониторинг, надо же знать как починить каждый тип кубиков. И тут уже появляется потребность в людях, заранее успевших познакомиться со стройкой и починкой нужного типа кубиков. Чем больше разнообразных кубиков, тем тем сильнее на длинной дороге нужнее специалисты, хотя на стометровке можно обойтись и без них.
N-Cube
23.11.2022 14:54+1Если вам для поддержки каждого скрипта нужен отдельный специалист, то они и не программисты вовсе, а очень дубовые мартышки.
BlackMokona
23.11.2022 15:19+2https://www.linkedin.com/in/matthewtejo
Парень ушёл до покупки Маском Твиттера.
anone9466
24.11.2022 00:03+4Спорный момент. Я сейчас на крупном (по кодовой базе) проекте, который на старте писали человек 30. Сейчас на суппорте 4. Да, бывают долгие инвистигейты, на два-три дня, перед реализацией задачи, но вполне справляемся. Система работает, ни разу крупных факапов (за последний год) не было. Да, спроектировано была хорошо.
Возможно, что в твиттере реально было перенасыщение программистов. И он не сломается под ноль. Просто в течении какого-то времени будет меньше новых фич, и все.
Тем более, что как по мне, твиттер это не какой-то рокет саенс.
Ktator
24.11.2022 00:35+4Надёжность любой системы не выше надёжности самой ненадёжной её части
Нет, это только если система топологически эквивалентна цепочке. Как только мы дублируем части системы, она становится надёжнее отдельных частей.
Заметьте, в тексте упомянуто, твиттер пережил падение целого датацентра, то есть, оказался надёжнее даже такой крупной части системы.
ForSokolov
23.11.2022 13:54+29Ну а почему бы и нет?..
Напомним, что Mesos был изначально разработан компанией Twitter и в 2010 году передан в руки фонда Apache
N-Cube
23.11.2022 14:57+1Есть большая разница между компанией твиттер в 2010 году и автором, пришедшем в эту компанию работать спустя много лет. А из статьи автора следует, что это лично он все сделал, а у компании твиттер есть единственное достижение - что лично его на работу приняли.
Che-Hov
23.11.2022 13:03+5Поживем - увидим.
Очень интригует, что же выйдет из этой ситуации с Твиттером.
scruff
24.11.2022 11:49https://s00.yaplakal.com/pics/pics_original/0/1/1/17410110.jpg
Пока всё очень даже норм выходит. Лишний балласт кидают за борт
exwill
23.11.2022 13:18+7я уверен, что где-то внутри таятся баги
Собственно остальное можно было и не писать.
...
Я знаю где, я знаю как
Я не гадалка, я маньяк
PZ1
23.11.2022 13:36+7для 5 лет как-то маловато заслуг и работы))). Все-таки не зря Маск их увольняет.
TimsTims
24.11.2022 02:19+3Ещё бы! Откуда там заслуги, если делать было нечего?
Команда получала примерно по одной заявке в неделю, и почти никогда она не была критически важной. В смены дежурства у нас часто случалось так, что не было ни одной заявки.
Возможно, статья - это красивый пиар-ход (заговор?), ведь он здесь всю статью так тонко и на грани описывает и подтверждает, что все эти увольнения были не зря)
Semy
25.11.2022 00:45+1Вообще-то это нормально, когда собрали систему, всё работает нормально, а команда занимается поддержкой системы и R&D. В случае поломки они все будут работать в поте лица. Но надо, что бы было кому работать в этот момент. Избавляться от команды нельзя, нельзя и кидать их на другие направления. Оптимизации возможны, но хороший менеджер не будет увольнять команду только потому, что всё работает.
TimsTims
25.11.2022 00:51+1Вы всё верно выше описали, ребята молодцы. Душа твиттера по ним плачет.
но хороший менеджер не будет увольнять команду только потому, что всё работает
Он увольняет их не потому что они такие молодцы молодцы, а потому-что у компании скоро закончатся деньги, и все разработки придётся похоронить. Выбрал наименьшее зло так сказать
Хороший менеджер будет увольнять (это очень трудно, поэтому он и крутой менеджер).
Плохой менеджер будет банкротить (Набрать +10000 человек, когда есть деньги? Да легко! Что с ними потом делать? Это будет не моя проблема!).
PS: Конкретно его Маск не увольнял)
Borkau
23.11.2022 14:38+1А этот инженер где-то пишет, что он был уволен именно Маском? Не ушел сам, не был выпнут еще раньше или другие варианты? Вроде нет. То есть, додуманное читателем - на совести читателя, классика.
BlackMokona
23.11.2022 15:18+1Нашёл в Линкедине. Его уволил не Маск, и не менеджер по поручению Маска, и даже не он сам ушёл в знак протеста против Маска....
https://www.linkedin.com/in/matthewtejo
Senior Site Reliability Engineer
май 2017 – авг. 2022 5 лет 4 месяца
А Маск купил компанию 28 октября 2022 , причём до самого конца сохранялась интрига купит или нет.
NeoCode
23.11.2022 20:16+1Интересно, а вот уволившиеся сотрудники, если их действительно 80%... не случится ли так что они организуются и создадут какой-нибудь Новый Твиттер?
BlackMokona
23.11.2022 21:12+11Не организуют по той же причине, по которой Маск не создал свой Твиттер. Аудитория не будет перебегать в новый.
ogost
24.11.2022 11:47Назрел вопрос: при уходе с одной прошлой работы меня настоятельно просили подписать что-то вроде "соглашение о не-конкуренции" (извиняюсь, русскоязычный термин мне не знаком), в котором говорилось, что я не буду хэдхантить у них и создавать похожий продукт. У нас это филькина грамота. Насколько распространена такая практика на западе? Если практикуется, то имеет ли хоть какую-то юридическую силу? А в РФ?
kryvichh
24.11.2022 13:13По сути это запрет применять наработанные знания и навыки в своей области. Которые для программиста являются основным источником пропитания.
anone9466
24.11.2022 19:01+1Насколько распространена такая практика на западе?
Распространена, и имеет силу. Но, при этом, слышал, что обязуются платить часть зп, во время всего оговариваемого срока. В некоторых пишут что вообще нельзя программированием заниматся.
В РФ силы не имеет никакой.
Вот вики, про сша- https://en.wikipedia.org/wiki/Non-compete_clause#United_States
Там и про другие страны есть
playnet
24.11.2022 23:02+1На западе имеет силу почти всё что подписали. В рф - нужно разделять "не работать" и "не делиться знаниями как у других". И если словесное описание сложно притянуть за интеллектуальную собственность, то даже за мелкие части утянутого кода серьезно может получить как работник, так и работодатель. Интеллектуальная собственность, коммерческая (и особенно военная) тайна продолжают действовать. Но как-то ограничить "вот тут работать не можешь" может только суд, и договор причиной этого не может являться никак. Уволился - денег не платят - всё, все подписанные документы такого рода автоматом ничтожны. А на западе даже без оплаты может иметь силу, тут надо внимательнее читать и хранить свой контракт.
eltardowut
24.11.2022 00:16Ну всё работает, что характерно.
euroUK
24.11.2022 13:31+1Ну имхо 20k твитов в секунду это немного
speshuric
24.11.2022 14:31Для какого-нибудь ETL отдельно - немного. Для картины, когда эти же 20К надо показывать прямосейчас миллионам пользователей - уже не так мало.
euroUK
24.11.2022 18:16-1Это придуманная бизнес цель. Ничего не произойдёт если не все люди узнают новость через 30 секунд вместо пары секунд а потом ещё какое-то количество за пару минут. Это не биржевая торговля. Люди сами себе придумывают задачи и их решают.
Если Макс твитнул текст и я его увидел не через секунду а через пару минут никто не умрет. Если я ретвитнул его Пете, а Петя его получил не через 5 секунд а через пять минут никто не умрет.
Если статистика популярных твитов обновиться с задержкой в пару минут тоже ничего страшного.
Balling
25.11.2022 13:25Вы и так видите это все через пару минут. Колокольчик там или фишка blue твиттера. А вот если F5 нажимать то все лучше.
znhv
24.11.2022 11:10Оно и так понятно, что инфраструктура будет работать в любом случае, ведь для этого и вводили SLO SLI, но что касается новых фич и тд, здесь уже не известно. Возможно выход новых — будет занимать много времени, а может и нет.
ganqqwerty
24.11.2022 11:54Я вроде давненько проработал в отрасли, а все еще не понимаю. Вот мужик вроде полезный. Наверное, таких надо много, человек двадцать. Ну ладно, давайте округлим и будет СТО! Но что делают остальные 7.5 тысяч?
v1000
24.11.2022 12:51+1Напоминает историю, когда для полета на Луну потребовалось из деталей Шаттла создавать практически с нуля новую ракету, потому что документация на Сатурн 5 была утеряна.
Любая сложная система должна быть задокументирована, чтобы не зависить от людей, которые ее создавали или поддерживали. Иначе это просто курсовик по программированию, принцип работы которого только в голове у написавшего его студента.
BlackMokona
24.11.2022 23:32Не утеряна, просто все фирмы и производственные линии, как и старые производственные методы , станки, материялы и люди которые на них работали уже ушли в историю
v1000
25.11.2022 10:43Когда я читал на эту тему историю, там главная мысль была в том, что чертежи-то сохранились, но не сохранились "приписки" к чертежам, и прочие "обработки напильником", знания о которых могли быть только в умах людей, которые этим занимались. Вот и получилось, что даже если сделать новые детали по старым чертежам, они будут работать совсем не так, как те, которые в итоге были установлены на саму ракету. А это значит, их нужно снова разрабатывать и тестировать с нуля. А в таком случае получается проще всю ракету начать разрабатывать с нуля.
Dr_Faksov
25.11.2022 04:19+1C технаследием обычно плохо. В общем случае –если вещь была сделана в прошлом веке штучно или мелкосерийно, и с тех пор не производилась, то дешевле и проще сконструировать по-новой, чем воспроизводить старый техпроцес.
С чем столкнётесь при воспроизведении?
1. Документация. Она никогда не полная. Не потому что лень писать, а потому что содержит ссылки на общеизвестные, на момент написания, характеристики устройств. Вроде « все посадочные размеры совпадают с сушилками АМ-15» А вот документацию на эти сушилки вы хрен найдёте. Хотя тогда их было как грязи, своеобразный производственный стандарт. Ну и да, изменения и дополнения к документации обычно хранятся отдельно. Если хранятся
2. Материалы. С тех пор появились материалы с гораздо лучшими, чем тогда характеристиками, что делает использование оригинальных материалов спорным. С тех пор исчезли материалы с гораздо лучшими, чем сейчас характеристиками. Потому что сейчас они, как и тогда были на вес золота, и это не фигура речи. Правда тогда вес считался 1 к 1, а сейчас может и до 10 к 1 доходить. Ну и опасность для здоровья\природы с тех пор пересмотрели.
3. Оборудование. Как производственное, так и измерительное. Как правило – уникальное, сделанное под конкретный проект. И разобранное за ненадобностью.
Как пример: для изготовления двух 6 –метровых зеркал Большого Азимутального Телескопа была построена печь способная расплавит 45 тонн оптического стекла (на одно зеркало) и практически моментально, без пузырения, переместить расплав в форму. Была создана электропечь, которая годами охлаждала отливки со скоростью ОДНА ДЕСЯТАЯ градуса в сутки. По всему объёму печи. Иначе – риск растрескивания. И соответственно система гарантированного энергопитания печи.
Ну и шлифовально-полировальная машина. Куда без неё. А точность у машинки измерялась в микронах, при 6-метровом плече. Ах да , ещё вакуумная камера, для алюминирования. Она единственная сохранилась и используется по сей день.
А самое главное – ЛЮДИ. Которые имели ОПЫТ.
Jianke
25.11.2022 12:28Как пример: для изготовления двух 6 –метровых зеркал Большого Азимутального Телескопа была построена печь способная расплавит 45 тонн оптического стекла (на одно зеркало) и практически моментально, без пузырения, переместить расплав в форму. Была создана электропечь, которая годами охлаждала отливки со скоростью ОДНА ДЕСЯТАЯ градуса в сутки. По всему объёму печи. Иначе – риск растрескивания. И соответственно система гарантированного энергопитания печи.
Ну и шлифовально-полировальная машина. Куда без неё. А точность у машинки измерялась в микронах, при 6-метровом плече. Ах да , ещё вакуумная камера, для алюминирования. Она единственная сохранилась и используется по сей день.
А самое главное – ЛЮДИ. Которые имели ОПЫТ
Напомнило сюжетную линию с колоколом фильма Андрей Рублёв. https://www.youtube.com/watch?v=lpKOqRilQto
vassabi
в общем : как видно - там еще есть довольно много надежности у старой системы.
Если оставшиеся красноглазы успеют построить новую систему и перебежать на нее быстрее, чем ляжет старая - то наверно никто и не заметит, что там внутри что-то поменялось.
А так - у всех были даунтаймы и потери в БД дельты от новых данных и последнего бекапа :)
Sergeant101
Ну такого рода сложные системы в одночасье не ломаются, если нет злого умысла.
С уходом специалистов они просто начинают потихоньку деградировать.
Время деградации зависит как раз от "запаса прочности" и добротности системы.