Системная структура предприятия it компаний - 4.1. Структура ИТ подразделения и органы управления ИТ предприятия
Выбор оргструктуры ИТ-подразделения
IT компания и ее структура
Информационные технологии предприятий
Организационная структура компании IT-Решения
ИТ - архитектура предприятия
IT отдел и его структура
Только полноправные пользователи могут оставлять комментарии. TM Feed Хабрахабр Geektimes Тостер Мой круг Фрилансим. Хабрахабр Публикации Пользователи Хабы Компании Песочница. Приводится опыт создания и эксплуатации ИТ системы компании, состоящей из примерно 10 сотрудников. И некоторые рассуждения на тему: Это взгляд со стороны директора компании, а не ИТ специалиста, без углубления в технические вопросы практической реализации. Особенностью нашего бизнеса, предопределившей принятые решения, было и остается недопустимость потери данных. Задача создания своей ИТ системы была нами поставлена и решена в году. Прошедшее время полностью подтвердило правильность принятых тогда решений. Основным требованием, как уже отмечено, было: Основной используемый в компании софт — обычный офисный пакет, 1С бухгалтерия. Что тогда не требовалось, так это: Естественно выбранное решение сравнивалось прежде всего с обычной одноранговой сетью. В итоге была выбрана структура с терминальным сервером на ОС WINDOWS , организованного на простом специализированном сервере не самосборка. Дисковое хранилище данных с аппаратной реализацией RAID 1 массива. Отдельное сетевое хранилище для резервных копий основных данных, включая слепок ОС на сервере, с автоматическим по расписанию архивированием. Для выхода во внешний мир использовался отдельный роутер-коммутатор. Сервер был размещен локально, в том же здании, где располагаются рабочие места сотрудников. Запуск системы и последующее обслуживание терминального сервера сразу был поручен специализированной ИТ компании. До сотрудников было доведено следующее условие: Это позволило сразу правильно сориентировать людей, где можно и нужно хранить свои данные. И соответственно практически вся работа сотрудников компании проходила и проходит сейчас в терминальном режиме. За прошедшее время уже 5 лет был только один серьезный сбой, когда после смены физического канала выхода на Интернет из-за рассогласования скоростей работы оборудования провайдера и нашего роутера пропал Интернет. Вылечилось обновлением прошивки в роутере. Подтвержденные опытом эксплуатации плюсы данного решения сейчас могут быть сформулированы следующим образом: Фактически действительно обеспечивается при разумных стартовых затратах высокая надежность хранения данных. Система пригодна для профессиональной удаленной поддержки. При необходимости сравнительно легко можно переехать в другой офис — требуется только перевезти сервер и локальные машины и включить все это в транспортную сеть нового офиса конечно с облаком это еще проще, но все познается в сравнении. Локальные машины могут быть любого типа и дешевыми, никаких специальных требований к ним не предъявляется. В то же время со временем стали проявляться и относительные недостатки такого решения: Защита данных не является максимально высокой, такой которая уже вполне достижима в современных условиях. В частности система не защищена от серьезных физических повреждений сервера условно — пожар в серверной. Терминальный сервер не очень хорошо приспособлен для работы с тяжелыми или многочисленными WEB приложениями. В связи с начальным отказом от виртуализации на сервере исключительно по мотивам экономии мы были вынуждены мириться с потенциальной возможностью перерыва в работе конечно без потери данных!!! В этой связи структура нашей ИТ системы была дополнена следующим образом: Был принципиально ограничен выход в Интернет непосредственно с терминального сервера. В случае работы, например, по системе Банк-Клиент — на сервере хранились только данные, а сама программа Банк-Клиент запускалась с какой-либо локальной машины, которая по одноранговой сети обращалась к данным на сервере, который в этом случае играл роль файл-сервера. Для решения проблемы физической защиты данных было организовано дополнительное хранение текущих и архивных копий данных в облаке. Почему и когда все же не стоит полностью отказываться от своего сервера и переходить на работу только с облаком, несмотря на привлекательность соответствующих предложений. В теории при работе в облаке все просто замечательно. Ваша компания при этом попадает в полную зависимость от ИТ компании, предоставляющей соответствующий облачный сервис. И даже если Вы вначале выбрали супер надежную компанию со временем она может увы, это жизнь потихоньку деградировать, а Ваши то данные все у нее. И даже перейти в другое облако без поддержки специалистов первой ИТ компании, вы не сможете. Критически важен оказывается Интернет канал. А по закону подлости, как раз тогда когда он Вам позарез нужен, проблемы с ним и случаются. Если для Вас важным является обеспечения конфиденциальности секретности данных, то надо либо проводить какой-то независимый технический аудит предполагаемого к использованию облачного сервиса, либо все же ориентироваться на собственный локальный сервер. Дело в том, что некоторые технические реализации облачных технологий допускают смешивание прав пользователей из разных компаний, вследствие чего сотрудники одной компании, работающей в облаке, могут получить доступ к данным другой компании, работающей в этом же облаке. В целом по нашему мнению можно считать относительно безопасным такой вариант ИТ системы с учетом оговорок относительно соблюдения конфиденциальности данных: Терминальный сервер в облаке с одновременной организацией собственного дополнительного сетевого хранилища данных локальный файл-сервер для хранения актуальных текущих копий всех Ваших данных. На этом же своем локальном сервере можно хранить текущий кэш данных, что снизит трафик по внешней сети и повысит скорость работы. А следующий шаг в развитии ИТ системы компании логически выглядит так — переход на систему виртуальных рабочих столов, расположенных на собственном сервере или в облаке технология DaaS. При этом у Вас должно быть независимое хранилище данных расположенное физически в другом месте и обслуживаемое желательно другой сервисной ИТ компанией. Плюс, если работаете с облаком, желателен сервер для локального кэширования текущих данных. ИТ система , терминальный сервер , надежность данных. Управление проектами автора , 2,2k публикаций. Управление разработкой автор , публикаций. Управление e-commerce 99 авторов , публикация. Терминология IT 40 авторов , 86 публикаций. Бизнес-модели автора , публикаций. Управление продуктом авторов , публикаций. Карьера в IT-индустрии автор , 1,1k публикаций. Управление персоналом авторов , публикации. Основные подходы 2,1k 5. Добавить в закладки Мнение со стороны системного администратора, видевшего аналогичное решение: Нет, не надо так делать. Даже если всем вашим десяти пользователям нужен одинаковый софт — не надо так делать. Браузер с кучей анимированных картинок может запросто подвесить всю сессию, если используется, например, Thinstation в качестве бесплатного тонкого клиента. Он будет гореть, умирать, но заменяться на такой же хлам. Лицензий на windows на машинах при этом явно нет. Десяток человек, одновременно активно работающих с дисками — и винчестерам уже печально. Никакой надежности запрет на выход в интернет с данного сервера вам не даст, если пользователи могут перемещать документы с локальных машин на сервер и обратно. Насмерть зависший процесс у одного из пользователей запросто приведёт к тому, что перезапускать необходимо будет весь сервер. Как вам, вероятно, стоило сделать: Регулярное резервное копирование компьютеров целиком. Сейчас это можно сделать через Veeam Endpoint Backup, например. Виртуализация сервера, либо кластеризация сервисов. Если у вас умер компьютер — вы просто покупаете аналогичный или меняете умершую часть, после чего прекрасно восстанавливается бэкап. Если у вас умер сервер — вы не потеряли возможность работать. Софт прекрасно работает на компьютерах, а в силу того, что это не простейшие дешевые калькуляторы — пользователи не ругаются на тормоза и невозможность открыть пару документов. И всем этим хозяйством можно будет нормально раздельно управлять. Необходимость обновить банк-клиент для бухгалтера не приводит к необходимости перезапуска сервера. Обновление очередного ПО для очередных закупок не приводит к необходимости перезапуска сервера. Более того, у вас исчезает единая точка отказа. Если вы купите второй физический сервер — вы сможете настроить их работу либо так, чтобы пользователи даже не заметили, что что-то случилось при использовании кластера 1С , либо с коротким перерывом на подъем реплики на резервном сервере при использовании виртуализации. Вы пишете правильные вещи. На основании своих знаний и того, что один раз видели подобную систему. Я же во-первых не теоретизирую, а всего лишь описываю реальный опыт реальной компании. И полученный опыт — за мое решение. Оно уже 5 лет без сбоев работает. Во вторых, Вы почти не уделили внимания главному требованию — обеспечить при минимальных затратах самую большую как только можно надежность хранения данных. В Вашем варианте такой же надежности можно достичь только поставив RAID массивы на каждое рабочее место что дорого или же путем скрупулезного выполнения обслуживающим персоналом своим айтишником или сторонней компанией — без разницы всех алгоритмов бэкапирования. Теоретически в этом ничего сложного нет. Практически вмешивается человеческий фактор и от надежности создания резервных копий если вся надежность только на них остаются только воспоминания. Ну и безусловно такое решение, как я описал, подойдет не для всех. И об этом я прямо написал: Но всем у кого подобные же условия и требуется высокая надежность хранения данных — категорически рекомендую сделать что то подобное. Да, эту систему легко отдать на централизованное обслуживание в компанию где работают грамотные специалисты. Возьмут хотя сейчас и будут навязывать облачные решения. И это для меня как директора большой плюс. А сколько будет стоить точнее стоила бы 5 лет назад Ваша структура? Проблемы которые реально были — это перестал работать СД привод, стал чрезмерно сильно шуметь вентилятор. Думаю это не те проблемы, о которых вообще стоит говорить. В отношении зависших процессов. Тогда никакие зависания процессов в принципе не страшны. Ну а поскольку, повторюсь, я описываю реальный опыт, хотелось бы обратиться ко всем, желающим поставить минус — обоснуйте пожалуйста свою негативную реакцию. Сделанное вами представляется настолько удивительно неоптимальным, что даже сложно всерьёз аргументировать. Пока могу придумать единственное оправдание такой вашей архитектуры — бюджет. Об этом вы не сказали ни слова, а было бы очень интересно узнать. Хотя бы порядок затрат. Про бюджет я написал. Фактически новые вложения были менее тысяч рублей. Не надо ничего аргументировать. Приведите пример не придуманной, а работающей системы, стоящей примерно столько же и гарантирующей ту же степень надежности хранения данных, что и описанная мною. На сегодня, с учетом нового резервного копирования в облако, она почти совершенна. Более высокая надежность может быть достигнута только при затратах на порядок больше. Вот поэтому я про статью в целом директор компании и ИТ-специалист должны быть разные люди. Раз уж делимся опытом, то поделюсь своим. Три небольших сервера Ceph на любом недорогом железе мы использовали восстановленные Fujitsu 3. Ещё один сервер так же малой мощности под 1С-сервер в web-файловом исполнении и под Calculate Directory Server такой же Fujitsu, но с большей ОЗУ 4. Все машины на относительно недорогом железе, но с достаточно большим количеством ОЗУ. Система разворачивается по PXE на клиентских машинах. Ввод новой машины занимает время загрузки оной на компьютере. База резервируется раз в час. Всё работает уже почти 3 года без нареканий и ввод нового кабинета занимал время вставки двух коннекторов в разъём и протяжки кабеля. Windows только у бухгалтера на ноутбуке, но с бухгалтерией у ИТ всегда особые отношения. В своё время очень хотелось реализовать VLAN структуру, но мне на ту компанию стало совсем не хватать времени и мы расстались. Оглядываясь назад понимаю, что сейчас при помощи OpenStack можно было бы всё реализовать ещё более красиво. Цена такого решения сейчас специально решил посмотреть: Данная система не то что такая же по надёжности, что и описанная Вами, но и гораздо более надёжная. В итоге мы получаем сервисы: DNS, DHCP, AD, Mail, NAS, Proxy, 1C. Узким местом является сервер 1С и CDS, но сами данные потерять невозможно хотя дуракам всё возможно. Итак, я директор это не модельная игра, я действительно директор , Вы системный администратор, который предлагает мне сделать несколько , сколько нужно дешевых серверов. Я знаю, что есть такие понятия как виртуальные сервера и терминальный сервер. И тогда я Вас попрошу ответить на такие вопросы: На основании чего Вы считаете, что много простых и дешевых серверов надежнее одного профессионального сервера, на котором можно поднять систему виртуальных серверов? Где физически будет храниться база знаний ну упростим — база документов и данных компании и как Вы обеспечите надежность их основного места хранения дублирование данных в облако — это уже дополнительная защита от потери данных. Если у меня сейчас 5 сотрудников и 5 локальных машин и все, а вскоре я планирую увеличить количество сотрудников в 2 раза — не правильнее все же будет организовать сразу терминальный сервер? Что удобнее и дешевле в обслуживании — один физический сервер с системой виртуальных серверов или несколько отдельных простых серверов? Сервисы даже не заметят, что один сервер умер. Удвоение людей — удвоение нагрузки. А придет ещё 5 сотрудников — и старый терминальный сервер станет бесполезным, придется брать новый. Один сервер — это единая точка отказа. Отсутствие дублирования — это простой и перебои в работе бизнеса. Так что ответ здесь — несколько серверов в рамках бюджета, на которых развернуть систему виртуализации с возможностями прозрачной миграции ВМ между серверами. В большинстве случаев для этого понадобится специализированная система хранения с высокоскоростными интерфейсами типа Fibre Channel и хорошими аппаратными контроллерами RAID. Главное — насовать в них побольше памяти 2. Как раз на этой самой системе хранения. Надёжности можно отсюда добавлять например путём создания или использования географически удалённого хранилища, собственного или арендованного 3. Размазав нагрузку по нескольким серверам вы внезапно увеличиваете общую пропускную способность и получаете систему на вырост. Терминальные сервера — довольно странная вещь. Зачем, если даже летний компьютер имеет достаточно мощности для нормальной офисной деятельности я не имею в виду понты и тяжёлые специализированные приложения. Но и там терминальный сервер не спасёт. Надо только задаться целью и мониторить. Ну и 4Гб в такой конфигурации хватит за глаза. Есть опыт создания на коленке системы хранения в обычном ATX-корпусе с RAID-контроллером и FC, работающем на специализированной сборке Linux запамятовал, как называется, а искать лень. Коллеги, мне кажется, что вы обсуждаете два подхода к обеспечению надёжности системы. Первый подход заключается в уменьшении количества точек отказа представлен автором, но не стоит забывать, что и один сервер в себе таит с десяток точек отказа , второй — резервирование узлов которое увеличивает вероятность отказов, но снижает их влияние на систему. Но, простите, это не взаимоисключающие, а взаимодополняющие подходы! Обратите внимание, автор допускает перерыв в работе бизнеса дня. За это время можно, даже находясь в регионе, слетать в Мск и привезти новый сервер! Соответственно для некоторого бизнеса и такой вариант является достаточным. Для другого, возможно, будет даже избыточен, для третьего — недостаточен и т. Думаю коллеги DaemonGloom и pred8or более чем достаточно привели доводов на ваши вопросы. Fujitsu RXS6 весьма хороший 1U сервер, с хорошим встроенным RAID контроллером. А где в Вашей конфигурации база знаний будет храниться? Я думаю Ceph вполне себе подойдёт. Хотя ещё круче будет развернуть на тех же 3х серверах LAMP и MediaWiki. Причём здесь вообще терминальный сервер? Вас как будто загипнотизировали… 4. Когда кластер, тогда лучше много серверов. Обновляться гораздо легче без остановки работы. Собственно в новом комментарии, которое я уже написал в конце обсуждения, я уже отметил, что терминальный сервер — это важная, но частная особенность конкретной реализации. Кластер на технологии Ceph или нечто аналогичное по функционалу — это конечно здорово, если его можно сделать по имеющемуся бюджету и есть исполнители, которые это умеют. В то же время и один сервер, как показывает наш опыт, надежное решение, если там есть аппаратный RAID и это не обычный офисный компьютер, в который добавили память это к тому, что можно называть профессиональным сервером. Аппаратный рейд не даст вам уровень защиты данных лучше, чем даст ОС или софт-рейд. Вы всего лишь исключаете ошибку драйвера софт-рейда и добавляете вероятность сбоя контроллера, помноженную на проблемы с переносом массива на другие устройства. Память не registered, один блок питания. Спасибо за ссылку по сравнению аппаратного и программного рейдов. С трудом, но прочитал и комментарии. Однако все не так очевидно. Да есть много ситуаций, когда программный рейд лучше быстрее, дешевле и т. А вот с Виндоуз уже не всегда программный рейд выигрывает. Именно такие выводы получаются от чтения того, что Вы порекомендовали. Если серьезный производитель HP в моем случае интегрирует в свой сервер аппаратный рейд, то наверно он это делает вполне обдуманно, а не для того, чтобы развести нас на деньги. Вот в чем Вы безусловно правы — так это в том, что на качестве сервера, особенно единственного, экономить надо осторожно. Я тут у себя пожалуй палку экономии перегнул. Я так понимаю вы предлагаете развернуть linux сервер 1C в файловом варианте, где базы будут лежать в кластере Ceph, а юзеры будут сидеть через браузер в 1С? Но тогда мы дважды упираемся в ограничение по скорости сети и проблемы с репликацией и восстановлением файловых баз. Да у 1С в файловом варианте базы живут гораздо хуже SQl-ных. В нашем случае база не планировала расти до Гб и файлового режима на 10 максимум одновременно работающих пользователей хватало. База находится на сервере, но снапшоты базы лежат на Ceph. Сидеть в 1С через браузер уже давно не нужно ибо клиент 1С умеет подключаться к web-серверу. В принципе 1С клиент на Linux работает вполне сносно. Впрочем, насколько я знаю та компания скоро перейдёт на SQL, так как их становится всё больше. На данный момент ПК нужны только для работы с 3д графикой, или для подключения всяких разных аппаратиков типа кассового или плотера… и т. Возможно для юзеров лучше полностью уйти в облоко и отказаться от физических серверов. Знаю одну контору которая работает аналогично тому как описано в статье, но они использовали ESXi затем сменили вроде на KVM. И все у них хорошо. Покупали БУ сервер HP ML G6. Простите, а какое вы используете железо и какой софт на терминалах? Xeon 2шт на сервер, HP ML G6. Как я понял из публикаций, вы используете тонкие клиенты HP. На первом попавшемся сайте, продающем такие устройства, цены начинаются от 30 тысяч за устройство. Купить обычный офисный компьютер c профессиональной версией Windows — дешевле. Автор, Вами представлен один из многих подходов для реализации офисной инфраструктуры. Хорошо, конечно, что Вы имеете представление о том, какое время Вы допускаете на восстановление и, что именно для Вас важнее. Но подавляющее большинство директоров в принципе этого не представляют. И системные администраторы плодят железки не потому, что они такие плохие. И та же Ваша сопровождающая организация пожмёт плечами и скажет: И предъявить им будет нечего. На сисадмина хоть поорать можно, почему он не предусмотрел, что именно в этот момент накроется мать и не купил запасную. Вы описали просто один из подходов к реализации инфраструктуры в определённых условиях. Он не хорош, он не плох — он один из. Его главный плюс в том, что для Вашей организации он достаточен. Подходит ли он для всего малого бизнеса? Лучше напишу отдельным комментарием, чем ответом в одной из веток. Мнение начинающего системного администратора. В самом начале Вы сразу сказали, что Директор, а не Айтишник. В этом вся проблема. Ещё проблема — узость мышления. Возможно, верное в плане экономии денег, но оно не оптимальное в плане надёжности данных. Вам требуется сверхнадёжность при минимальных затратах. Если у Вас только 1С и офисные программы на 10 сотрудников, то я бы тоже предложил терминальный сервер. Если набор программ для всех сотрудников одинаковый, то хватит и RDP. Если же разный софт, то лучше использовать виртуализацию рабочих столов. При любом раскладе для подключения к серверу достаточно тонкого клиента, а не полноценного компьютера. Сервер 1С должен быть отдельным сервером. Бэкап-сервер — тоже отдельный сервер. Разумеется, сервер может быть как виртуальным, так и физическим. Тут важнее разделение ролей по разным серверам, чтобы при корректировке работы одной из ролей не возникало проблем с другими. Кстати, Вам не говорили, что профили пользователей даже на локальных компьютерах можно сделать перемещаемыми и хранить на сервере тогда повышаются требования к сети? И бить по пальцам за сохранение на рабочем столе. А ещё я не встречал вирус-шифровальщик, который умеет шифровать по UNC-путям. Ещё бочка дёгтя в ложке мёда: Вы в курсе, что Вам надо: И не абы какая любая от любого офиса, к слову. У Вас есть шанс влететь на штраф при проверке. Спасает лишь то, что их почти не устраивают мелким компаниям. А маски-шоу Вам тоже не угрожают? Шанс такого — нулевой? Никогда не экономьте на IT. В фанатизм ударяться не стоит — никакой экономии, но и сверхзатрат не нужно. От того, как Ваши сотрудники управляют инструментом, зависит качество сделанной работы. И как результат — прибыль компании. Кратко Ваше решение характеризуется так: После первоначальных небольших шараханий — пошла интересная и полезная дискуссия. Есть общее замечание на тему приличности и необходимости директору компании самому вникать в некоторые общие вопросы ИТ системы. И здесь диретору надо или самому быть ИТ директором или нанимать на стороне не услуги системного администратора, а услуги ИТ директора. А пока вынужденно совмещая в одном лице и директора и ИТ директора вижу, что прошедшая дискуссия позволяет сформулировать некоторые общие принципы построения структуры ИТ системы, ориентированной на высокую надежность хранения данных компании. Так надо строить распределенную отказоустойчивую систему хранения данных, в которой: Резервные копии — это само — собой тоже. А дальше начинаются варианты. Можно взять как у меня один профессиональный сервер и сделать на нем систему виртуальных серверов чего я не сделал, а зря. Что лучше и надежнее при ограниченном бюджете для меня пока не очевидно. Вопрос о терминальном сервере решается в зависимости от конкретных потребностей бизнеса. Если как у меня новая компания, ничего нет, будет одинаковый софт — то лучше терминальный сервер. Если идет модернизация сложившейся стрруктуры с большим количеством локальных машин с разным софтом на разных рабочих местах, то терминальный сервер не нужен. И разумеется, если есть такая возможность по бюджету и по квалификации исполнителей , то надо иметь минимум два физических сервера один из них может быть в облаке и делать систему миграции виртуальных машин между серверами. У меня не профессиональные десктопы по лет непрерывно пашут и ничего. При должном то уходе. Мне оч сильно сдаётся что когда ваш чудо сервер накроется вы неделю будете воротать всё обратно до рабочего состояния, из которых 5 дней будете безуспешно пытатся развернуть бэкап ОС со всеми настройками и оставшиеся два дня будете ставить ОС с нуля и настраивать, заливать данные. Виртуализация в вашем случае нужна ровно для одного: Но я бы искал как уйти с: Есть конечно нюансы со считывателями штрих кодов, банк клиентами и прочим дерьмовым софтом, но в худьшем случае осталась бы машины с виндой. Виртуализация для не венды не шибко актуальна, при прямых руках. Аппаратный рейд — нафик не впёрся, если ОС не винда, даже без него намного лучше, в плане сохранности данных — переткнул диски в другую железку и понеслось, не надо искать такой же контроллер. Нисколько не сомневаюсь, что у Вас будет работать все и без проблем. Только вот моя задача была и остается сделать такую структуру, которая не требует постоянного наличия возле себя золотых рук. Описанная Вами опасность есть. Однако бэкапы — это прежде всего последняя линия обороны в хранении совсем даже не системы, а данных компании. Систему можно и восстановить, даже еще раз купить в крайнем случае, а вот утерянные собственные данные купить негде. Хотя и систему тоже бэкаппируют. Вдруг получится ее быстро восстановить. А основная линия обороны по защите данных — это горячее резервирование RAID массивы, кластеры. Совершенно не согласен с Вашим негативным восприятием виртуализации. Каюсь здесь у меня исключительно теоретические знания, так что пусть практики меня если что поправят. Но насколько я понимаю виртуализация на основе любой ОС полезна в следующих целях: Про аппаратный рейд — где то выше была небольшая дискуссия. У вас и первой линии нет. Того и гляди кто нибудь работая в терминале запустит очередной шифровальщик. Аппаратный рейд — вещь в себе. В целом его ниша это: К счастью у меня железо не дохло во время этого, но пару неприятных моментов было, когда до потери было совсем рядом: Город был не большой и нашлось оно в одном магазине. С программным рейдом под не виндой пробем не было. Под виндой как то буква на системном разделе слетела, но данным ничего не грозило. Засовывание отдельных приложений в виртуалку это усложнение администрирования, тк помимо администрирования приложения нужно ещё и за ОС следить. Венду проще сунуть в виртуалку, чем переставлять каждый раз когда она помрёт или когда нужно железо менять. Для отказустойчивого кластера одного сервера набитого виртуалками мало. Это явно не под силу автору. И лазейки всё равно остаются, вон на джаве есть локеры. Терминальный сервер это дорогое удовольствие от единственного вендора, по крайней мере для подавляющего большинства. Это ещё и единая точка отказа. Лёгкость администрирования на винде — видимая. И обычно решающий все проблемы — переустановка с нуля… Ну да, бэкапы тоже иногда помогают. Логов можно считать что нет — понять из них без грепанья по исходникам ничего не возможно а исходников нет. Метки лучше разделять запятой. Первая российская материнская плата массового сегмента 23,3k Интересные публикации Хабрахабр Geektimes. Ограничение скорости обработки запросов в nginx. W3C всё-таки одобрил стандарт DRM для HTML5 GT. Как я боролся с комарами. Личный опыт и тесты на себе GT. Neuralink — Будущее, которое сложно себе представить. Вы будете его частью GT. Как запутать аналитика — 5. Linux все еще не торт. Китай заблокирует VPN для частных лиц GT. Разделы Публикации Хабы Компании Пользователи Песочница. Информация О сайте Правила Помощь Соглашение Конфиденциальность. Услуги Реклама Тарифы Контент Семинары.
Концерт посвященный дню матери статья в газете
Замена термостата холодильника атлантсвоими руками
Картинка со схемой слова
Последние новости в дагестане про абдулатипова
Болит кишечник в разных местах
Старые карты сергиево посадского уезда московской губернии