Александр Хамидулин

В Proxmox не получится работать с хранилищем с типом LVM как с обычным каталогом. Если нужно подцепить образ диска к виртуальной машине, скопировав его откуда-то, или скачать его, то это проще выполнить с хранилищем типа Directory, или через NFS либо SMB/CIFS. Достаточно залить образ диска в поддерживаемом формате в каталог виртуальной машины и дать команду qm rescan. Перемещать образы дисков между хранилищами можно с помощью команды Disk Action -> Move Storage (или эквивалент в cli - команда qm move-disk)

exten => _[7,8]9XXXXXXXXX,n,Dial(${Tch-Channel-1},35,mD(9w8${EXTEN:1:10})),
где:
${Tch-Channel-1} = DAHDI/g0/77777
77777 - номер для ответа в вашей терминологии
35 - продолжительность вызова по каналу
m - музыка в режиме ожидания (можете заменить на r и будете слышать что творится в канале вместо музыки)
D(набор двухтональный, он же DTMF...)
9 - префикс
w - пауза 1 сек.

Вы можете организовать у себя общение в чем угодно, в чем сами согласитесь, или что введет ваше руководство. Например, в одной компании где я пиэмлю и девелоплю, у нас...скайп! С группами под разное. Раньше было вообще 10 групп, счас свели до пары штук, отдельно на департменты, отдельно по городам, ну и общий трёп.
Тут важно что для быстрой связи нужно чтобы человек мог быстро даже в трамвае увидеть сообщение и отреагировать. Потому ориентируйтесь просто на наиболее распространенные мессенджеры, которые точно есть у большинства. Так что ХипЧат или Лайн видимо будет не вариант. Зато Вайбер какой нить, или Телеграм, или даже Скайп - вполне может подойти. Они кроссплатформенные, привычные и не нужно этой хрени с инвайтами как в Слаке. К слову, в другой конторе у нас как раз Слак, но там сотни народу из разных стран, и тоже разбиты по странам, технологиям и т.п.
В слаке удобно что есть группы, ты их мож видеть и подписываться. В Скайпе/Вайбере/Телеграме такой фокус не получится.
Вообще, если спуститься на более низкий уровень, то общатся можно по протоколу ирки, или жаббера, и раз вы айтишники, это как раз не должно вызвать сложности. Да хоть аськой(представьте что у меня аська до сиз пор есть, пятизнак, и всё такое, и в онлайне постоянно.)
А, тут приходим к еще одному нюансу - обратите внимание на мессенджер Franz, и какие он может мессенджеры.Удобная штука, я постоянно например пользую, у меня там 13 сервисов подвязаны, среди них два скайпа, телеграм и та самая аська.

Вообще, если говорить про всякие хипстерские штуки, то топовыми счас есть тот самый Слак, Microsoft Teams, riot(matrix) и mattermost
А дальше уже куча мелочи всякой. Например, есть у меня подписка на quip.com, даже футболка мне и жене есть от них, прислали. Но в постоянном пользовании им пользоваться как то не получилось, неудобно.
То есть, смотрите на массовые

• riot.im (другие клиенты для сети матрикса см тут matrix.org/docs/projects/try-matrix-now.html)
  
• mattermost.org
  есть минус с правами пользователей, которых в бесплатной версии просто нету, только энтерпрайз. Так, например, любой пользователь может удалить канал.
  

Из мелочи можно пробовать

• rocket.chat
  фаворит на сегодня
  
• gitter.im
  от гитхаба
  
• tribescale.com
  
• ora.pm
  
• glip.com
  стоит попробовать, из за анлим условий в бесплатном тарифном плане.
  
• flock.com
  довольно приятный и эргономичный внешне, но надо тестить на команде, и сравнивать тариф, все ли подходит в бесплатном
  
• zulipchat.com
  немного неудобный UX и навигация
  

Обратил бы еще активно внимание на вот этот проект:
humhub.org

А документы смотрите на

• wikisuite.org/Software
  
• bookstackapp.com/
  

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

Если же говорить о комбайнах, где будет и проджект менеджмент, и общение, и вот это вот всё, то конечно продукты от Атлассиан это стандарт. Дальше еще больше укорененный Бейскемп(где для общения есть Кемпфайр), ну и конечно Битрикс24, куда без него. Ну и quip.com, с групоовым чатом тоже под это заточен.

Базовые знания:
1. Создаем новый репозиторий в GitHub/Bitbucket.
2. Создаем папку проекта с файлом .gitignore (в нем пишем форматы файлов и пути, которые не должны отслеживаться системой контроля версий: всякие логи *.log, временные файлы *.tmp, пути /trash и т.п.)
3. В терминале находясь в данной директории инициализируем git.
git init
4. В ST пишем код и сохраняем в этой директории.
5. В терминале смотрим изменения, добавляем и ставим в очередь на коммит в git все созданные файлы/директории

git status
git add -A

6. Делаем коммит-мерж
git commit -m 'Initial commit'
7. Добавляем связь с удаленным репозиторием

git remote add origin <адрес репозитория из п.1 на GitHub/Bitbucket>
git remote -v

8. Пушим локальные изменения в удаленный репозиторий
git push origin master

Далее в процессе работы повторяем пункты 4-8.

Если нужно затянуть новый удаленный репозиторий
git clone https://github.com/repo

Для ветвления сначала достаточно знать только checkout и merge.

Вам следует создавать Docker-контейнер таким образом, чтобы в нём работал один ключевой процесс (у которого будет PID 0), завершение которого означает завершение работы контейнера. Код выхода этого процесса будет кодом выхода контейнера. Вы сможете увидеть его в выводе `docker ps --all`. Подробнее здесь: each-container-should-have-only-one-concern. Это не означает, что в контейнере должен быть всего один процесс, но должен быть один такой процесс, жизненный цикл которого неразрывно связан с жизненным циклом контейнера.

Логи этот процесс должен писать в STDOUT и STDERR - тогда Вы их сможете увидеть с помощью `docker logs ` и перенаправить куда надо с помощью драйвера логирования, настроенного в Докер-демоне. Подробнее здесь: View a container's logs

Отвечу по документации...

1. Формат.
Для вас лучше это делать в plain text, т.к. даже будучи в консоли, вы всегда сможете их прочитать.
Форматы: любой из .md, .rst, asciidoc (т.к. есть возможость визуализировать из в pretty format) внутри различных систем.

2. Хранение
Способ хранения - только SCM (какой именно: git, svn, hg или более старое - не знаю, что вы используете). Поясню, почему не файловая система:
- вам важно знать state вашего оборудования на определенный момент. Т.е. вы всегда можете посмотреть конфигурацию, актуальную месяц/два назад и выявить проблемы.
- вы всегда можете сделать diff и посмотреть изменения. Часто, это должно быть сделано не просто сейчас, а "внезапно" :)

Использовать atlassian confluence, как говорят выше, я для ваших задач НАСТОЯТЕЛЬНО НЕ рекомендую. Причина:
- вы привязаны к вендору (даже за 10 баксов за мин. лицензию). Если вы откажетесь от вендора вы НЕ сможете выцепить ее - только copy/paste или покупкой плагинов за сотни баксов.
- у атлассиана разметка жестко забита в софт. Там нельзя выгрузить wiki разметку (кроме как при покупке плагинов за сотни баксов, например, scroll)
- и, самое главное, вам не просмотреть текст в консоли!

3. Визуализация
Здесь все зависит от количества времени, которое вы готовы потратить. Знаю, существуют решения для визуализации md для обычный wiki. Здесь вам лучше погуглить оптимальный вариант для предыдущих двух пунктов.

OVA -- это формат VMware скорее. Там внутри обычно .vmdk (диск) и .ovf (описание конфигурации виртуального железа).

Вам нужно содержимое диска, а виртуалку можно и руками создать. ВиртуалБокс позволяет сконвертировать vmdk диск в формат vhd, который вы можете затем подсунуть в Hyper-V. OVA -- это tar-архив. Распакуйте его tar-ом, вытащите vmdk и сконвертируйте его с помощью VBoxManage в .vhd:

VBoxManage clonehd --format vhd disk1.vmdk disk1.vhd

Затем руками создаёте на Hyper-V виртуалку и ей подсовываете этот vhd.

1. Хранить надо так, что если пропадут данные с любых 3-х серверов, то на оставшемся - будут все данные и не держать все "яйца в одной корзинке".
2. Конечно, нужно создать надёжное шифрование и распределение доступа к данным.
3. Спроектировать систему отказоустойчивости и предусмотреть защиту от DDoS.
4. Сконфигурировать политики сетевой безопасности и правила хождения пакетов.
5. Raid10 на каждом сервере - минимум.

1. Вам нужно точно определить кол-во одновременных вызовов. По опыту могу сказать, что редко когда именно все внутренние номера вдруг одновременно разговаривают. У меня в одном офисе обзвонщиков (холодные звонки), примерно на 300 человек, зарегистрировано одновременных 80-90 одновременных вызовов. Одни разговаривают, а у других - писи-каки или ням-ням-ням :))) А в административных офисах телефония вообще практически не нагружена. Соответственно, если база на 6 трубок позволяет только 3 одновременных вызова - это не беда.

2. Посчитать пропускную способность канала исходя из 100 Кбит/сек на 1 разговор ( при кодеках ulaw/alaw + служебной информации). Допустим у вас будет 10 одновременных звонков - значит для IP-телефонии необходимо выделить полосу 1 Мб/c.

3. Далее, если необходим безшовный роуминг по зданию - вам уже предложили Kirk и подобные решения. Но они достаточно дороги для небольшой компании. Если же этого требования нет - то вы сами выбрали решение - отлично справятся Gigaset или Panasonic TGP 500/600.

4. Действительно ли вам необходимы только трубки? Иногда разумнее выдать их только определенным сотрудникам, а остальных посадить на стационарные телефоны, Yealink или Grandstream или другие.

Ну про АТС писать уже не буду, тут в любом случае со своей аналоговой переберетесь куда-нибудь на FreePBX и подобные, вам решать.