Сложно :) На практике это делается значительно проще- при наличии серьезных проблем специалисты 1С обращаются к администраторам баз данных. Состояние MS SQL оценивается по ряду параметров, начиная с количество заблокированных процессов, суммарному времени ожидания блокировок, чтению в минуту и т.д. Если цепочка блокировок- кильнуть злодея и скинуть его текст на 1С, пусть разбираются. Если с сервером все нормально- ищите проблему на 1С. Если нет- вычисляется запрос с наибольшим логическим чтением, самый грузовой запрос. ТОП-10 таких запросов. Внимательно изучается. Как правило, по тексту специалисты 1С уже могут понять что за модуль. Кроме того, sqlplan самого тяжелого запроса может содержать миссинг индекс, что является крайне удобной подсказкой. При этом за базой нужно внимательно следить, планово проверять на предмет миссинг индекс, создавать необходимые индексы. Самовольное создание индексов- это нарушение лицензионного соглашения, потому такие вещи нужно делать с 1С, чтобы штатными средствами. Профайлер- вообще не используется, бесполезен. Куда интересней системные вьюхи. Традиционной проблемой для 1С является забытый параметр в джоине, при этом выборку разносит и запросы становятся крайне тяжелыми. Выловить такой запрос и передать разработчикам- решить проблему.
Первое, что здесь можно посоветовать- поработать флажками трассировки влияющими на оптимизатор, начиная с хита, 4199. Иногда это позволяло здорово улучшить ситуацию. Второй момент- 1С совершенно дико работает с MS SQL Server. У меня иногда получались цифры чтения из памяти на уровне 2-3 Тб в минуту, что совершенно дико и радикально отличается от традиционных параметров работы. Память это уже ни средство кэширования данных а какой-то аЦЦкий математический механизм. В остальном же, как только появляются проблемы с временными таблицами- ловите программистов и правьте им карму. Зачастую они в джоин какой-то параметр забывают вставить, вследствие чего временные таблицы разносит до несуразности. Проблема 1С в том, что эти временные таблицы сложно увидеть, сложно понять кто и как их заполняет, зачем в дальнейшем используют. Но в плане запроса видно количество строк, ровс, иногда оно несуразно. Следует отметить, что программисты, как правило, реагируют на замечания адекватно, узкие места устраняют.
У нас есть базы больше десятка Тб. Каждая из таких баз- это сотни файлов, все крупные объекты секционированы. То есть, сделать реорг всем объектам- вполне реалистичный сценарий. А вот если в 10 Тб базе два файла, лога и данных, при этом самая крупная таблица с индексами занимает половину- во, там дождаться шансов нет- но такая ситуация свидетельствует о крайне неудачной архитектуре приложения. Так-то базы размером до 600-800 Гб вполне комфортно поддаются обслуживанию, даже без секционирования.
У нас используются пороги 10 и 30 процентов, подсмотрели в стандартном скрипте Микрософт. Но здесь тонкость, в стандарт редакции ребилд блокирует таблицу, онлайн может только ентерпрайз. Если таблица большая- это нарушает работу пользователей. Второй момент- при ребилде создается копия таблицы. Для больших таблиц это может закончиться катастрофическим ростом базы, под это может просто не хватить места на диске (СХД). Есть и третий момент. Запрос фрагментации- процедура долгая. Куда проще огульно делать реорг всем таблицам кроме самых крупных, по списку. По ресурсам то на то и выходит. С самыми крупными смотреть отдельно. Зачастую они накопительные, меняются мало и фрагментируются не сильно.
Не очень понятны претензии к шринку. На практике место на СХД ограничено, выделяют его неохотно, после отдельных операций в базе разносит некоторые файлы. Я обычно формирую единый скрипт по всем файлам базы, первый заход транкейтонли, дальше просто шринк, во всех случаях ограничение времени. Да и можно вычислить в каком из файлов осталось много свободного места, отсортировать очередность. Запустил в студии- оно и давит. При этом в рамках свободного места стараюсь выполнять лесенкой, в несколько иттераций. Ребилд- очень нехорошая штука. Ребилд в стандарт редакции блокирует таблицу, ребилд создает копию таблицы. То есть, для больших таблиц ребилд упорото жрет место. Если таблица занимает треть базы- значит ее объем увеличится тоже на треть, потом это место будет освобождено. При этом база может запросто сожрать все место на диске. Вот тут и пригодится шринк. На практике для крупных таблиц лучше использовать только (исключительно) реоганайз. Можно исходить из того, что скорость чтения из базы для не самого могучего сервера на уровне 8-10 Гб в минуту. При перестроении индексов на это идет 1-3 Гб чтения в минуту. Вот из этого и нужно исходить. 800 Гб таблица (резервед, со всеми индексами) реорг часов 5, вполне реалистично.
Это все же ребячество, мол, они там без меня.. Что у них там будет то их проблемы, меня они не касаются никак. Но в мою бытность эта финансовая структура поддерживала программные комплексы на Украине, в России, в Грузии, в Латвии, на Кипре. Все это приходилось контролировать, под все это писать скрипты. Да и динамично все росло, увеличивались нагрузки и объемы. Сейчас я каких-либо контактов с действующими сотрудниками не поддерживаю, но судя по сообщениям в СМИ, дела у них не очень. Зарубежных структур уже нет, банк национализирован, против бывшего руководства уголовные дела. Многие бывшие коллеги работают в других организациях.
Здесь еще не затрагивается такой вопрос, с достижения некоторого уровня квалификации и доверия сотруднику поручается отдельное направление. С ним резко сокращает контакты руководство, только в самых общих чертах- он сам все и так знает. При этом уважение, ответственность, повышают зарплату- и резко увеличиваются переработки.
Работал это я в самом большом украинском банке, были периоды когда в месяц было три выходных или один выходной. В рабочее время следишь за серверами, все изменения в выходной. Изменения иногда накатываются очень непросто. Отгулов за переработку не давали, через какое-то время возникало состояние апатии и выгорания. Отдельно переработку не оплачивали, но даже если бы и оплачивали- не сильно оно и повлияло бы, в состоянии хронической усталости деньги воспринимаются абстрактно. И так годами.
Нынешний работодатель к переработкам относится значительно более щепетильно. Нет, и тут иногда авралы случаются, сервера капризничают, ночами звонят. Но, все же, плановые работы стараются проводить в рабочее время или, по крайней мере, не в выходные.
На этом принципе работали советские программируемые микрокалькуляторы, Б3-34, МК-61, МК-52. Там чтобы сложить 2 + 2 надо было набрать 2, стрелочку вверх, 2 а после +. Сначала крайне неудобно, потом привыкаешь. После с "техникой молодежи" на Луну сажаешь космические корабли :)
Несколько удивляют попытки создать на базе ARM нечто для вычислений, разные кластеры. С точки зрения изучения, тестирования- да, отличный полигон. Но практически вычислительная мощность так себе.. Сравнивал stress-ng очень простую материнку с впаяным Intel Celeron J4125 и Raspberry Pi 4 Model B (4*Cortex-A72). Они набрали, соответственно, 24123 и 8752. То есть, производительность малинки составляет 36% от производительности очень заурядного процессора классической архитектуры. То есть, единица вычислительной мощности у малинки дороже.
Примерно такие же мысли витали в начале 90-х, многие попробовали заниматься бизнесом. И тут выяснилось, что бизнесом заниматься СЛОЖНО. Люди теряли время, деньги, имущество. Изначальный оптимизм улетучивался после встречи с реалиями жизни.
Нет, какое-то время при дикой инфляции и колоссальных запасах материальных ценностей на советских заводах тотальное предпринимательство еще работало. Но после сдулось под ноль, последние всплески закончились в самом начале 2000х.
Есть мнение, что если размер записи велик а в индекс вынесено нужное varchar поле, то размер индекса может быть значительно меньше размера таблицы. Кластерный индекс (или куча) пусть 10 Гб, индекс 1 Гб. Поиск по такому индексу даже лайком будет идти значительно быстрей.
Несколько лет назад в одной очень большой организации внедряли зарплатный проект на 1С. А он, что называется, «не взлетел». Разработчики голову ломали, админы, сотрудники отдела-эксплуатанта. Перепробовали все что можно, на MS SQL Server шли дидлоки, процесс сбивался. Я там долгое время просил кое-что сделать, но когда все остальное перепробовали- разрешили. Проблему решили 4 индекса по таблицам на 80 мегабайт. Аж запрыгало.
Здесь еще нужно понимать, самовольное создание индексов в 1С является нарушением лицензионного соглашения. Начальство на это смотрит крайне подозрительно, потому любой удачный индекс после следует удалить и создать легальными средствами 1С. Зачастую процесс поиска таких индексов выносится на тестовую среду, в исключительных случаях (критическое падение производительности) могут разрешить что-то попробовать на продакшене.
В дальнейшем была проведена большая работа по анализу кода. Основной объект анализа- процедурный кэш, анализируется в момент наибольшей нагрузки, высоких блокировок и высокой дисковой активности.
Для понимания- по счетчику Page lookups/sec|SQLServer:Buffer Manager удалось установить, что в отдельные моменты запрос данных из памяти сервера достигает 2 Тб в минуту и более (!!). То есть, память используется не как средство ускорения доступа к информации на СХД а как некий математический механизм, эта нагрузка разительно отличается от рабочей нагрузки других серверов.
Выявлялись наиболее ресурсоемкие запросы, оптимизировались индексами либо передавались разработчикам на изменение кода. При системном подходе никаких ин-мемори таблиц и колумнсторе индексов не понадобилось, и так замечательно заработало.
Кроме того, хорошо поработали с флажками трассировки.
На сегодняшний момент проблемы оптимизации 1С возникают только при внедрении новых задач или существенных изменениях (меняются запросы).
Идея интересная, спасибо. Но что нужно отметить- фольга не очень удачный материал. Прочность ограничена, сильные порывы ветра, сильные скачки давления в помещении могут ее порвать. Кроме того, надо будет это обслуживать, через какое-то время узкие полости начнут забиваться пылью, пакет придется либо промыть либо разобрать.
Ну и второе- наличие дополнительной ступени могло бы еще повысить КПД. Дело в том, что встречное направление движение потоков в обычном рекуператоре позволяет извлечь больше тепла из отходящих газов, на входе в пакет воздух с улицы начинает греться едва теплыми отходящми газами, которые уже отдали свое тепло. Продвигаясь по устройству повышается температура поступающего воздуха- температура отходящих газов все более повышается, они еще не отдали свое тепло на входе.
В Вашей схеме они поступают как бы под углом 90 градусов, последовательного прогрева может и не получиться, потому лучше бы еще одну такую же коробку.
Ну и если уж там все равно вентилятор- есть смысл сбрасывать этот теплый воздух не в атмосферу а прогонять в трубе под пешеходной дорожкой, зимой она практически не будет нуждаться в уборке снега. Очень небольшой плюс температуры обеспечивает стабильную очистку от снега и льда.
Все очень просто, если сотрудникам нужно обслуживать какие-то простые вещи, грубо говоря, подавать детали или тыкать кнопки- то шум на производительность влияния не оказывает.
Но если надо думать, если речь о какой-то сложной интеллектуальной работе а в кабинете постоянно говорят- работы не будет. Если ваши сотрудники должны вычитывать документы или работать с технической документацией а рядом постоянно кто-то п… т — они будут делать ошибки, они не будут усваивать прочитанное.
Это мука, страдание- вместо работы сотрудники вынуждены выслушивать безумную ахинею, даже если это производственные вопросы- они в большом помещении не связаны с их работой. Они приходят на работу не выполнять некоторые задания а страдать.
В рабочем помещении должно быть тихо как в библиотеке. Надо поговорить- в переговорку. Поговорить по личным вопросам- взял телефон, вышел в коридор. Это обычные правила гигиены рабочего помещения, постоянно трепаться так же неуместно как ходить на работу в вонючем нижнем белье. Понимают это не все, потому в больших помещениях всегда (!) кто-то п… т, кашляет, шаркает. Там постоянно звонят телефоны. Там постоянно вонь от женщин не знающих меру в плане косметики.
Разумной альтернативой могут быть помещения со стеклянными стенами. Там вроде и все на виду и работе не мешает.
Первый обезоруживающий удар наносится в удобное для атакующего время. Окно может возникать раз в три дня- этого уже достаточно, дальше от этого остальные мероприятия. На деле- несколько раз в сутки. При этом небольшая доработка блока разведения может радикально изменить ситуацию, использовать можно будет, практически, на каждом витке.
Что до материалов, у них там на МКС постоянно экипаж находится. Можно хоть ежедневно что-то размешать, забирать, наблюдать.
Как вариант, можно было бы какой-то поршень пропихнуть сжатым воздухом. Допустим, плотный пакет из тряпок или что-то вроде этого (артиллерийский банник). С животным та еще проблема- то нужду справит, то сдохнет. Там тоже решения есть, тем же сжатым воздухом дунуть, но потом потрошки по всему научному прибору
Безумие. Проект начинается с разработки идеологии, баз, структур данных. В повер дизайнере умные люди неделями сидят вычисляя как будут взаимодействовать нужные таблицы и поля, куда какую размерность и т.д. Здесь же- аааа! Табуном затопчем! Флешмобом!
Продуманное и рациональное решение так не получится. При чем, это дыра навсегда- если завтра код можно будет переписать, то идеологию и структуры не изменишь, это повлечет за собой потребность заново все делать.
То есть, нормальной идеологии нет, нормального проекта нет, нормальной структуры БД нет, поддержки нет, обязательств разработчика нет. Есть куча говнокода очень спорной надежности.
Для условий Украины это можно сравнить с проектом iGov. Большой понт- большой пшик.
В 1988-1989 годах видел живые и рабочие «Эльбрус 2М», в Подмосковье. Футбольные поля со шкафами. Где-то до сих пор валяется книга по Эль-76, потрясающая была штука для своего времени, сам процесс компиляции был очень интересно устроен. Как бы это помягче сказать… само существование таких машин долго не признавали, потом Горбачев на фоне инженерного пульта «Эльбруса» что-то лепетал про суперкомпьютеры.
В 1989 в ДМЕТИ был установлен компьютер СМ-4, потрясающая машина. Потрясающая тем, что изначально был вшит компилятор фортран и паскаль, кроме того, имелся графор- графическое расширение фортрана. Это позволяло невероятно просто управлять графопостроителем. Ни автокад конечно, но развести печатную плату плевое дело, главное пишущий инструмент с лаком вместо чернил вставить.
К слову так, в 1990 спаял свой первый компьютер, «специалист» (КР580ВМ1). Что интересно- из отечественных деталей, ВСЕ детали были отечественные. Схему печатали в «Моделист Конструктор», но я немного иначе делал, на запорожской плате. С 1986 года журнал «Радио» предложил свою версию, народ долго диспутировал что лучше.
Скажем так, в плане общего технологического уровня в СССР дела были очень даже хороши, все на уровне лучших мировых образцов. Но оценить этот уровень в военной сфере мешала секретность. В гражданской- отсутствие нормального механизма внедрения передовых технических решений и образцов.
Такие красивые прикиды у ребят могут быть вызваны спецификой полезной нагрузки. Если кратко, это ядерное оружие, «автобус». Сама система- средство обезглавливающих, обезоруживающих ударов против которого беспомощна СПРН.
Сложно :) На практике это делается значительно проще- при наличии серьезных проблем специалисты 1С обращаются к администраторам баз данных. Состояние MS SQL оценивается по ряду параметров, начиная с количество заблокированных процессов, суммарному времени ожидания блокировок, чтению в минуту и т.д.
Если цепочка блокировок- кильнуть злодея и скинуть его текст на 1С, пусть разбираются.
Если с сервером все нормально- ищите проблему на 1С. Если нет- вычисляется запрос с наибольшим логическим чтением, самый грузовой запрос. ТОП-10 таких запросов. Внимательно изучается. Как правило, по тексту специалисты 1С уже могут понять что за модуль. Кроме того, sqlplan самого тяжелого запроса может содержать миссинг индекс, что является крайне удобной подсказкой.
При этом за базой нужно внимательно следить, планово проверять на предмет миссинг индекс, создавать необходимые индексы. Самовольное создание индексов- это нарушение лицензионного соглашения, потому такие вещи нужно делать с 1С, чтобы штатными средствами.
Профайлер- вообще не используется, бесполезен. Куда интересней системные вьюхи.
Традиционной проблемой для 1С является забытый параметр в джоине, при этом выборку разносит и запросы становятся крайне тяжелыми. Выловить такой запрос и передать разработчикам- решить проблему.
Первое, что здесь можно посоветовать- поработать флажками трассировки влияющими на оптимизатор, начиная с хита, 4199. Иногда это позволяло здорово улучшить ситуацию.
Второй момент- 1С совершенно дико работает с MS SQL Server. У меня иногда получались цифры чтения из памяти на уровне 2-3 Тб в минуту, что совершенно дико и радикально отличается от традиционных параметров работы. Память это уже ни средство кэширования данных а какой-то аЦЦкий математический механизм.
В остальном же, как только появляются проблемы с временными таблицами- ловите программистов и правьте им карму. Зачастую они в джоин какой-то параметр забывают вставить, вследствие чего временные таблицы разносит до несуразности. Проблема 1С в том, что эти временные таблицы сложно увидеть, сложно понять кто и как их заполняет, зачем в дальнейшем используют. Но в плане запроса видно количество строк, ровс, иногда оно несуразно. Следует отметить, что программисты, как правило, реагируют на замечания адекватно, узкие места устраняют.
У нас есть базы больше десятка Тб. Каждая из таких баз- это сотни файлов, все крупные объекты секционированы. То есть, сделать реорг всем объектам- вполне реалистичный сценарий.
А вот если в 10 Тб базе два файла, лога и данных, при этом самая крупная таблица с индексами занимает половину- во, там дождаться шансов нет- но такая ситуация свидетельствует о крайне неудачной архитектуре приложения.
Так-то базы размером до 600-800 Гб вполне комфортно поддаются обслуживанию, даже без секционирования.
У нас используются пороги 10 и 30 процентов, подсмотрели в стандартном скрипте Микрософт. Но здесь тонкость, в стандарт редакции ребилд блокирует таблицу, онлайн может только ентерпрайз. Если таблица большая- это нарушает работу пользователей. Второй момент- при ребилде создается копия таблицы. Для больших таблиц это может закончиться катастрофическим ростом базы, под это может просто не хватить места на диске (СХД).
Есть и третий момент. Запрос фрагментации- процедура долгая. Куда проще огульно делать реорг всем таблицам кроме самых крупных, по списку. По ресурсам то на то и выходит. С самыми крупными смотреть отдельно. Зачастую они накопительные, меняются мало и фрагментируются не сильно.
Не очень понятны претензии к шринку. На практике место на СХД ограничено, выделяют его неохотно, после отдельных операций в базе разносит некоторые файлы. Я обычно формирую единый скрипт по всем файлам базы, первый заход транкейтонли, дальше просто шринк, во всех случаях ограничение времени. Да и можно вычислить в каком из файлов осталось много свободного места, отсортировать очередность. Запустил в студии- оно и давит. При этом в рамках свободного места стараюсь выполнять лесенкой, в несколько иттераций.
Ребилд- очень нехорошая штука. Ребилд в стандарт редакции блокирует таблицу, ребилд создает копию таблицы. То есть, для больших таблиц ребилд упорото жрет место. Если таблица занимает треть базы- значит ее объем увеличится тоже на треть, потом это место будет освобождено. При этом база может запросто сожрать все место на диске. Вот тут и пригодится шринк.
На практике для крупных таблиц лучше использовать только (исключительно) реоганайз. Можно исходить из того, что скорость чтения из базы для не самого могучего сервера на уровне 8-10 Гб в минуту. При перестроении индексов на это идет 1-3 Гб чтения в минуту. Вот из этого и нужно исходить. 800 Гб таблица (резервед, со всеми индексами) реорг часов 5, вполне реалистично.
Это все же ребячество, мол, они там без меня.. Что у них там будет то их проблемы, меня они не касаются никак. Но в мою бытность эта финансовая структура поддерживала программные комплексы на Украине, в России, в Грузии, в Латвии, на Кипре. Все это приходилось контролировать, под все это писать скрипты. Да и динамично все росло, увеличивались нагрузки и объемы.
Сейчас я каких-либо контактов с действующими сотрудниками не поддерживаю, но судя по сообщениям в СМИ, дела у них не очень. Зарубежных структур уже нет, банк национализирован, против бывшего руководства уголовные дела. Многие бывшие коллеги работают в других организациях.
Здесь еще не затрагивается такой вопрос, с достижения некоторого уровня квалификации и доверия сотруднику поручается отдельное направление. С ним резко сокращает контакты руководство, только в самых общих чертах- он сам все и так знает. При этом уважение, ответственность, повышают зарплату- и резко увеличиваются переработки.
Работал это я в самом большом украинском банке, были периоды когда в месяц было три выходных или один выходной. В рабочее время следишь за серверами, все изменения в выходной. Изменения иногда накатываются очень непросто. Отгулов за переработку не давали, через какое-то время возникало состояние апатии и выгорания. Отдельно переработку не оплачивали, но даже если бы и оплачивали- не сильно оно и повлияло бы, в состоянии хронической усталости деньги воспринимаются абстрактно. И так годами.
Нынешний работодатель к переработкам относится значительно более щепетильно. Нет, и тут иногда авралы случаются, сервера капризничают, ночами звонят. Но, все же, плановые работы стараются проводить в рабочее время или, по крайней мере, не в выходные.
На этом принципе работали советские программируемые микрокалькуляторы, Б3-34, МК-61, МК-52. Там чтобы сложить 2 + 2 надо было набрать 2, стрелочку вверх, 2 а после +. Сначала крайне неудобно, потом привыкаешь. После с "техникой молодежи" на Луну сажаешь космические корабли :)
Несколько удивляют попытки создать на базе ARM нечто для вычислений, разные кластеры. С точки зрения изучения, тестирования- да, отличный полигон. Но практически вычислительная мощность так себе.. Сравнивал stress-ng очень простую материнку с впаяным Intel Celeron J4125 и Raspberry Pi 4 Model B (4*Cortex-A72). Они набрали, соответственно, 24123 и 8752. То есть, производительность малинки составляет 36% от производительности очень заурядного процессора классической архитектуры. То есть, единица вычислительной мощности у малинки дороже.
Примерно такие же мысли витали в начале 90-х, многие попробовали заниматься бизнесом. И тут выяснилось, что бизнесом заниматься СЛОЖНО. Люди теряли время, деньги, имущество. Изначальный оптимизм улетучивался после встречи с реалиями жизни.
Нет, какое-то время при дикой инфляции и колоссальных запасах материальных ценностей на советских заводах тотальное предпринимательство еще работало. Но после сдулось под ноль, последние всплески закончились в самом начале 2000х.
Здесь еще нужно понимать, самовольное создание индексов в 1С является нарушением лицензионного соглашения. Начальство на это смотрит крайне подозрительно, потому любой удачный индекс после следует удалить и создать легальными средствами 1С. Зачастую процесс поиска таких индексов выносится на тестовую среду, в исключительных случаях (критическое падение производительности) могут разрешить что-то попробовать на продакшене.
В дальнейшем была проведена большая работа по анализу кода. Основной объект анализа- процедурный кэш, анализируется в момент наибольшей нагрузки, высоких блокировок и высокой дисковой активности.
Для понимания- по счетчику Page lookups/sec|SQLServer:Buffer Manager удалось установить, что в отдельные моменты запрос данных из памяти сервера достигает 2 Тб в минуту и более (!!). То есть, память используется не как средство ускорения доступа к информации на СХД а как некий математический механизм, эта нагрузка разительно отличается от рабочей нагрузки других серверов.
Выявлялись наиболее ресурсоемкие запросы, оптимизировались индексами либо передавались разработчикам на изменение кода. При системном подходе никаких ин-мемори таблиц и колумнсторе индексов не понадобилось, и так замечательно заработало.
Кроме того, хорошо поработали с флажками трассировки.
На сегодняшний момент проблемы оптимизации 1С возникают только при внедрении новых задач или существенных изменениях (меняются запросы).
Если модератор пропустит- небольшая моя статья на тему оптимизации MS SQL Server
www.digger.dp.ua/optimizaciya-ms-sql-server
Ну и второе- наличие дополнительной ступени могло бы еще повысить КПД. Дело в том, что встречное направление движение потоков в обычном рекуператоре позволяет извлечь больше тепла из отходящих газов, на входе в пакет воздух с улицы начинает греться едва теплыми отходящми газами, которые уже отдали свое тепло. Продвигаясь по устройству повышается температура поступающего воздуха- температура отходящих газов все более повышается, они еще не отдали свое тепло на входе.
В Вашей схеме они поступают как бы под углом 90 градусов, последовательного прогрева может и не получиться, потому лучше бы еще одну такую же коробку.
Ну и если уж там все равно вентилятор- есть смысл сбрасывать этот теплый воздух не в атмосферу а прогонять в трубе под пешеходной дорожкой, зимой она практически не будет нуждаться в уборке снега. Очень небольшой плюс температуры обеспечивает стабильную очистку от снега и льда.
Но если надо думать, если речь о какой-то сложной интеллектуальной работе а в кабинете постоянно говорят- работы не будет. Если ваши сотрудники должны вычитывать документы или работать с технической документацией а рядом постоянно кто-то п… т — они будут делать ошибки, они не будут усваивать прочитанное.
Это мука, страдание- вместо работы сотрудники вынуждены выслушивать безумную ахинею, даже если это производственные вопросы- они в большом помещении не связаны с их работой. Они приходят на работу не выполнять некоторые задания а страдать.
В рабочем помещении должно быть тихо как в библиотеке. Надо поговорить- в переговорку. Поговорить по личным вопросам- взял телефон, вышел в коридор. Это обычные правила гигиены рабочего помещения, постоянно трепаться так же неуместно как ходить на работу в вонючем нижнем белье. Понимают это не все, потому в больших помещениях всегда (!) кто-то п… т, кашляет, шаркает. Там постоянно звонят телефоны. Там постоянно вонь от женщин не знающих меру в плане косметики.
Разумной альтернативой могут быть помещения со стеклянными стенами. Там вроде и все на виду и работе не мешает.
Что до материалов, у них там на МКС постоянно экипаж находится. Можно хоть ежедневно что-то размешать, забирать, наблюдать.
Продуманное и рациональное решение так не получится. При чем, это дыра навсегда- если завтра код можно будет переписать, то идеологию и структуры не изменишь, это повлечет за собой потребность заново все делать.
То есть, нормальной идеологии нет, нормального проекта нет, нормальной структуры БД нет, поддержки нет, обязательств разработчика нет. Есть куча говнокода очень спорной надежности.
Для условий Украины это можно сравнить с проектом iGov. Большой понт- большой пшик.
В 1989 в ДМЕТИ был установлен компьютер СМ-4, потрясающая машина. Потрясающая тем, что изначально был вшит компилятор фортран и паскаль, кроме того, имелся графор- графическое расширение фортрана. Это позволяло невероятно просто управлять графопостроителем. Ни автокад конечно, но развести печатную плату плевое дело, главное пишущий инструмент с лаком вместо чернил вставить.
К слову так, в 1990 спаял свой первый компьютер, «специалист» (КР580ВМ1). Что интересно- из отечественных деталей, ВСЕ детали были отечественные. Схему печатали в «Моделист Конструктор», но я немного иначе делал, на запорожской плате. С 1986 года журнал «Радио» предложил свою версию, народ долго диспутировал что лучше.
Скажем так, в плане общего технологического уровня в СССР дела были очень даже хороши, все на уровне лучших мировых образцов. Но оценить этот уровень в военной сфере мешала секретность. В гражданской- отсутствие нормального механизма внедрения передовых технических решений и образцов.
Чтобы не повторяться, вот ссылка на мою короткую заметку www.digger.dp.ua/otkroem-malenkij-sekret-amerikanskij-bespilotnyj-shattl-x-37b-zachem-on-nuzhen