Ну вот возьмем ситуацию. Приходит задача нужно срочно прикрутить супер пупер фичу к продукту, после чего его продажи обещают взлетят на 10%. Расчетный экономический эффект запредельный. Задача вырывается в топы и отжирает ресурсы. В итоге никакого реального эффекта нет, колебания продаж находятся в пределах статистической погрешности.
Тогда вопросы будут к тем, кто рассчитывал и заказывал задачу, а не к ИТ. Если эффекта нет, то либо ТЭО было неправильно рассчитано, либо появились обстоятельства, на которые решение данной задачи никак не могло повлиять (общее падение спроса/продаж, деградация «продажников» и т.п.). Бороться средствами ИТ с такими проблемами, всё равно что пытаться остановить торнадо usb-вентилятором: глупо, но научит отделы при рассчёте пытаться оценить и будущую ситуацию.
Будут находится ушлые — те кто по блату или обманом будут получать ресурсы и терпилы — те кто пытается играть по честному.
Такой подход так или иначе вредит организации и с ним нужно бороться даже когда в компании деньги самосвалом выгребают. Шаги описанные в статье лишь повод организационно и культурно обосновать «посыл».
который нужен раз в год в том, что на следующий год он уже другой
Иногда реально выгоднее, чтобы какой-то отчёт формировали сами бухгалтера в Excel, нежели потратить ресурсы ИТ на вникание в детали задачи, доработку, тестирование и релиз. Если это будет использоваться всего раз, то нет и смысла это автоматизировать. В противном случае это двойная работа.
Всегда дешевле иметь одного спеца бухгалтер+1C, который подчиняется начальнику бухгалтерии, чем по отдельности бизнесаналитик, начальник ДИТ, чистый программист.
Во-первых, вы переходите от общего к частному. Компания в которой один программист способен справиться со всем потоком задач всей организации действительно выгодно иметь такую структуру. Но даже в статье рассматривался пример, когда программистов должно быть больше.
Во-вторых, очень тяжело и дорого быть спецом сразу в двух направлениях. Зачастую у программист+бухгалтера страдают оба направления. Программист должен знать предметную область настолько, насколько ему необходимо для решения задачи. Поэтому даже в статье приведён пример, когда сотрудники ИТ закреплены за определёнными направлениями.
Сам сталкивался с ситуацией, когда работал в сфере ЖКХ. Хотя были предоставлены все необходимые инструменты реально влияющие на бизнес, бухгалтера по прежнему в упор не хотели их использовать. Тогда я убедился, что проблемы были на 90% из-за лени бухгалтерии (ещё 10% это отсутствие финансирования и большие задержки зп).
Собственно поэтому та компания и развалилась. Они просто не смогли конкурировать.
Поддерживаю! Пачку задач и обосновать легче, и исполнить.
Единственным минусом будет то, что вместе с экономически обосноваными заказами могут и будут «просачиваться» необоснованные «хотелки».
В нашем случае база не планировала расти до 100Гб и файлового режима на 10 (максимум) одновременно работающих пользователей хватало. База находится на сервере, но снапшоты базы лежат на Ceph.
Сидеть в 1С через браузер уже давно не нужно ибо клиент 1С умеет подключаться к web-серверу. В принципе 1С клиент на Linux работает вполне сносно. Особой разницы в «глюках» с форточной версией не увидел.
Впрочем, насколько я знаю та компания скоро перейдёт на SQL, так как их становится всё больше.
Думаю коллеги DaemonGloom и pred8or более чем достаточно привели доводов на ваши вопросы.
От себя добавлю:
1. Что в Вашем понимании «профессиональный сервер»? А есть непрофессиональный? Fujitsu RX100S6 весьма хороший 1U сервер, с хорошим встроенным RAID контроллером.
2. А где в Вашей конфигурации база знаний будет храниться? Я думаю Ceph вполне себе подойдёт. Хотя ещё круче будет развернуть на тех же 3х серверах LAMP и MediaWiki.
3. Причём здесь вообще терминальный сервер? Вас как будто загипнотизировали…
4. Когда кластер, тогда лучше много серверов. Обновляться гораздо легче без остановки работы.
Вот поэтому (я про статью в целом) директор компании и ИТ-специалист должны быть разные люди.
Раз уж делимся опытом, то поделюсь своим.
1. Mikrotik RB951G-2HnD + 2 х D-Link DGS-1016
2. Три небольших сервера Ceph на любом недорогом железе (мы использовали восстановленные Fujitsu)
3. Ещё один сервер так же малой мощности под 1С-сервер в web-файловом исполнении и под Calculate Directory Server
(такой же Fujitsu, но с большей ОЗУ)
4. Все машины на относительно недорогом железе, но с достаточно большим количеством ОЗУ.
Система разворачивается по PXE на клиентских машинах. Ввод новой машины занимает время загрузки оной на компьютере.
Ко всему snapshot`ы всего хранилища дублируются на Dropbox каждый день в 00:00. База резервируется раз в час.
Всё работает уже почти 3 года без нареканий и ввод нового кабинета занимал время вставки двух коннекторов в разъём и протяжки кабеля. Windows только у бухгалтера на ноутбуке, но с бухгалтерией у ИТ всегда особые отношения.
В своё время очень хотелось реализовать VLAN структуру, но мне на ту компанию стало совсем не хватать времени и мы расстались.
Оглядываясь назад понимаю, что сейчас при помощи OpenStack можно было бы всё реализовать ещё более красиво.
Цена такого решения сейчас (специально решил посмотреть):
Микротик — 6 299
DGS-1016A 3 999x2=7 998
Fujitsu RX100S6 Core i3-540/8GB/500 GB SATA/2xGlan/PSU 350W — 19 200x4=76 800
1С Бухгалтерия 8.3 ПРОФ 10 800
1С лицензия на 10 рабочих мест 34 500
ИБП DEXP Rely Power 3000VA (2600Вт) 26 999
Шкаф б/у 10 000
Итого: 173 396 рублей без учёта стоимости рабочих мест и со всеми лицензиями
Когда я собирал всю эту систему, обошлось в 140к рублей (правда мы собирали на Xeon-процессорах).
Данная система не то что такая же по надёжности, что и описанная Вами, но и гораздо более надёжная.
В итоге мы получаем сервисы: DNS, DHCP, AD, Mail, NAS, Proxy, 1C. Узким местом является сервер 1С и CDS, но сами данные потерять невозможно (хотя дуракам всё возможно).
Прошу прощения, что поднимаю старую тему.
Если несколько линукс-серверов 1С поднять на разных машинах и одном кластере без активации лицензии, то количество подключений по прежнему будет 12? Или можно распределить по машинам?
Вынужден не согласиться. Коллега — профессионал....
Вы наверное меня не так поняли. Я за то, чтобы тот, кто «готовит», тот и критикует. Без «это решение г...! почему? мне так сказали.»
А насчёт свести в почте — идея хорошая. Если у вашего коллеги есть время и желание рассказать подробнее о подводных камнях, то я только за. Мне даже интересно, в чём загвоздка.
Это не та нагрузка, которой можно положить Elastic в правильной комплектации и настройке. Самым узким местом может быть приём записей без потерь, но RabbitMQ решает этот вопрос, поэтому доставка гарантирована. Другой вопрос, если поднимать всё «из коробки» без тонкого тюннинга: тогда с некоторой вероятностью всё грохнется и на 1к записей.
И…
К сожалению, сильно больше подробностей рассказать не могу, потому как занимаюсь эластиком не я сам, а коллега.
Без знания сути говорить, что что-то плохо работает не есть правильно.
Вы это говорите с учётом своего печального опыта? Если да, то не могли бы Вы более подробно рассказать?
Пытаюсь сымитировать ситуацию на своей тестовой площадке, но до сих пор не получилось добиться деградации кластера. Максимум 5 минут, и то, я не назвал бы это деградацией (деградация наблюдается только при запросах на именно те индексы, которые восстанавливаются). Поделитесь, может быть даже в рамках новой статьи.
«будущее за» тем, что выберет администратор в своём серверном парке. Конечно администратор мог и ошибиться с выбором, но если продукт развивается и к нему привык персонал, то скорее всего этот продукт будет использоваться ещё очень долго.
Главное, чтобы конечный инструмент мог и решал бОльшую часть задач администратора. И чем больше задач решаются «из коробки», тем удачнее выбран продукт. Ярким примером для меня был Мегафон, где «костыль» подпирается «костылём», просто потому что рабочий продукт не решает необходимых задач.
Поэтому (я слегка «скапитаню») нужно выбирать не то, что «все твердят», а то, что реально подходит.
Спасибо! Очень интересно и красочно описана тема. Возьму за пример вашу статью, когда буду помогать изучать ООП своим подопечным.
жаль кармы не хватает, чтобы «плюсануть» публикацию.
Тогда вопросы будут к тем, кто рассчитывал и заказывал задачу, а не к ИТ. Если эффекта нет, то либо ТЭО было неправильно рассчитано, либо появились обстоятельства, на которые решение данной задачи никак не могло повлиять (общее падение спроса/продаж, деградация «продажников» и т.п.). Бороться средствами ИТ с такими проблемами, всё равно что пытаться остановить торнадо usb-вентилятором: глупо, но научит отделы при рассчёте пытаться оценить и будущую ситуацию.
Такой подход так или иначе вредит организации и с ним нужно бороться даже когда в компании деньги самосвалом выгребают. Шаги описанные в статье лишь повод организационно и культурно обосновать «посыл».
Иногда реально выгоднее, чтобы какой-то отчёт формировали сами бухгалтера в Excel, нежели потратить ресурсы ИТ на вникание в детали задачи, доработку, тестирование и релиз. Если это будет использоваться всего раз, то нет и смысла это автоматизировать. В противном случае это двойная работа.
Во-первых, вы переходите от общего к частному. Компания в которой один программист способен справиться со всем потоком задач всей организации действительно выгодно иметь такую структуру. Но даже в статье рассматривался пример, когда программистов должно быть больше.
Во-вторых, очень тяжело и дорого быть спецом сразу в двух направлениях. Зачастую у программист+бухгалтера страдают оба направления. Программист должен знать предметную область настолько, насколько ему необходимо для решения задачи. Поэтому даже в статье приведён пример, когда сотрудники ИТ закреплены за определёнными направлениями.
Сам сталкивался с ситуацией, когда работал в сфере ЖКХ. Хотя были предоставлены все необходимые инструменты реально влияющие на бизнес, бухгалтера по прежнему в упор не хотели их использовать. Тогда я убедился, что проблемы были на 90% из-за лени бухгалтерии (ещё 10% это отсутствие финансирования и большие задержки зп).
Собственно поэтому та компания и развалилась. Они просто не смогли конкурировать.
Единственным минусом будет то, что вместе с экономически обосноваными заказами могут и будут «просачиваться» необоснованные «хотелки».
Порою ошибки позволяют развить вполне себе интересные направления, как, например, Ваша статья.
Так было бы проще, но тогда Вы не освоили бы реализацию IIS+Django.
Правда я бегло просмотрел код и не нашёл намёка на шифрование.Планируете ли добавить?
Сидеть в 1С через браузер уже давно не нужно ибо клиент 1С умеет подключаться к web-серверу. В принципе 1С клиент на Linux работает вполне сносно. Особой разницы в «глюках» с форточной версией не увидел.
Впрочем, насколько я знаю та компания скоро перейдёт на SQL, так как их становится всё больше.
От себя добавлю:
1. Что в Вашем понимании «профессиональный сервер»? А есть непрофессиональный? Fujitsu RX100S6 весьма хороший 1U сервер, с хорошим встроенным RAID контроллером.
2. А где в Вашей конфигурации база знаний будет храниться? Я думаю Ceph вполне себе подойдёт. Хотя ещё круче будет развернуть на тех же 3х серверах LAMP и MediaWiki.
3. Причём здесь вообще терминальный сервер? Вас как будто загипнотизировали…
4. Когда кластер, тогда лучше много серверов. Обновляться гораздо легче без остановки работы.
Раз уж делимся опытом, то поделюсь своим.
1. Mikrotik RB951G-2HnD + 2 х D-Link DGS-1016
2. Три небольших сервера Ceph на любом недорогом железе (мы использовали восстановленные Fujitsu)
3. Ещё один сервер так же малой мощности под 1С-сервер в web-файловом исполнении и под Calculate Directory Server
(такой же Fujitsu, но с большей ОЗУ)
4. Все машины на относительно недорогом железе, но с достаточно большим количеством ОЗУ.
Система разворачивается по PXE на клиентских машинах. Ввод новой машины занимает время загрузки оной на компьютере.
Ко всему snapshot`ы всего хранилища дублируются на Dropbox каждый день в 00:00. База резервируется раз в час.
Всё работает уже почти 3 года без нареканий и ввод нового кабинета занимал время вставки двух коннекторов в разъём и протяжки кабеля. Windows только у бухгалтера на ноутбуке, но с бухгалтерией у ИТ всегда особые отношения.
В своё время очень хотелось реализовать VLAN структуру, но мне на ту компанию стало совсем не хватать времени и мы расстались.
Оглядываясь назад понимаю, что сейчас при помощи OpenStack можно было бы всё реализовать ещё более красиво.
Цена такого решения сейчас (специально решил посмотреть):
Микротик — 6 299
DGS-1016A 3 999x2=7 998
Fujitsu RX100S6 Core i3-540/8GB/500 GB SATA/2xGlan/PSU 350W — 19 200x4=76 800
1С Бухгалтерия 8.3 ПРОФ 10 800
1С лицензия на 10 рабочих мест 34 500
ИБП DEXP Rely Power 3000VA (2600Вт) 26 999
Шкаф б/у 10 000
Итого: 173 396 рублей без учёта стоимости рабочих мест и со всеми лицензиями
Когда я собирал всю эту систему, обошлось в 140к рублей (правда мы собирали на Xeon-процессорах).
Данная система не то что такая же по надёжности, что и описанная Вами, но и гораздо более надёжная.
В итоге мы получаем сервисы: DNS, DHCP, AD, Mail, NAS, Proxy, 1C. Узким местом является сервер 1С и CDS, но сами данные потерять невозможно (хотя дуракам всё возможно).
Так автор и скопипастил.
Всё в рамках «закона».
Если несколько линукс-серверов 1С поднять на разных машинах и одном кластере без активации лицензии, то количество подключений по прежнему будет 12? Или можно распределить по машинам?
Вы наверное меня не так поняли. Я за то, чтобы тот, кто «готовит», тот и критикует. Без «это решение г...! почему? мне так сказали.»
А насчёт свести в почте — идея хорошая. Если у вашего коллеги есть время и желание рассказать подробнее о подводных камнях, то я только за. Мне даже интересно, в чём загвоздка.
И…
Без знания сути говорить, что что-то плохо работает не есть правильно.
Пытаюсь сымитировать ситуацию на своей тестовой площадке, но до сих пор не получилось добиться деградации кластера. Максимум 5 минут, и то, я не назвал бы это деградацией (деградация наблюдается только при запросах на именно те индексы, которые восстанавливаются). Поделитесь, может быть даже в рамках новой статьи.
Главное, чтобы конечный инструмент мог и решал бОльшую часть задач администратора. И чем больше задач решаются «из коробки», тем удачнее выбран продукт. Ярким примером для меня был Мегафон, где «костыль» подпирается «костылём», просто потому что рабочий продукт не решает необходимых задач.
Поэтому (я слегка «скапитаню») нужно выбирать не то, что «все твердят», а то, что реально подходит.
Добавлю уточнение в публикацию.
Сейчас добавлю в публикацию.
жаль кармы не хватает, чтобы «плюсануть» публикацию.