На самом деле известный случай. Но тут можно только спекулировать. Такие активности вряд ли ограничены какой-то одной системой, и единственный индикатор для простых смертных — реакция вендора. В OpenBSD не замалчивают. По моему, это плюс.
Вообще, пришлось предварительно изучить спеку, прежде чем покупать железку под это дело. Полагаю, что на случайно выбранном железе может много чего не работать. Но «по спеке» проблем не было. Были «задачи, которые надо было решить» :)
Наличие определенного набора элементов дизайна на сайте. Именно по этому пункту, к сожалению, не могу раскрыть детали — устно подписался неразглашать полученные знания на публику. Sorry.
По другим пунктам готов делиться всем, что знаю.
Из техничного:
1. UNIX от мАла до велИка;
2. IT Management;
3. Продающие сайты. Как делать высокую конверсию посетителей в звонителей и анкето-заполнятелей;
Не техничное, да всяко-разное:
1. Стартапер;
2. Переезд в большой город (аж два раза и оба успешно);
Строго говоря, Change — это любое изменение в любом CI (Configuration Item).
CI — элемент Configuration Management — процесса в рамках которого ведется учет всех элементов инфраструктуры — серверов, АТС, лицензий на софт, процессов, контрактов… и связей всего этого хозяйства друг с другом.
CI характеризует каждую единицу инфраструктуры в разумных деталях.
Если это сервер, то в документации записано, что он «такой-то модели», «имеет такой-то IP», имеет связь с такой-то СХД, привязан к такому-то контракту и так далее. В общем это отдельная тема.
Если говорить о Release Management. Слышал о нем, как части ITIL… не готов прокомментировать. Ретируюсь :)
Спасибо за коммент. Подписываюсь под каждым пунктом.
Да, в маломальски средней компании уже можно использовать и Change Windows и апруверов и Disaster Recovery.
Что мне нравится в ITIL — это логичность. До любого процесса можно дойти самостоятельно и внедрить без боли. Поэтому, когда знакомишься с методиками, в голове возникает только одна мысль: «Хм, Ну да. А что можно иначе?»… тем и обоснована её популярность.
О, это — один из самых важных пунктов. Если все на самом деле просто, то все шаги заполняются за пять-десять минут. Если же всё сложнее, то это знак к тому, что стоит записать шаги по пунктам, чтобы ничего не забыть. К слову сказать, если шаги продуманы качественно, то время применения изменений сокращается в разы, потому, что можно мозг практически отключить и сконцентрироваться на мониторинге ситуации, а не думать о том, что делать дальше.
Естественно, Change Management ради Change Management — это бред, и очень хорошо, когда это понимают и руководство и технари. Главное — чтобы работа шла хорошо.
В свободном доступе по большому счету только общая информация, но для понимания её обычно хватает. Можно немного найти по фразе «itil resources free». Если есть конкретные или общие вопросы — задавайте, м.б. следующим постом на них отвечу :)
https://www.openbsd.org/66.html
Из техничного:
Veritas Storage Foundation (vxfs) — достаточно специфичные знания, м.б. кому пригодится.
По другим пунктам готов делиться всем, что знаю.
1. UNIX от мАла до велИка;
2. IT Management;
3. Продающие сайты. Как делать высокую конверсию посетителей в звонителей и анкето-заполнятелей;
Не техничное, да всяко-разное:
1. Стартапер;
2. Переезд в большой город (аж два раза и оба успешно);
CI — элемент Configuration Management — процесса в рамках которого ведется учет всех элементов инфраструктуры — серверов, АТС, лицензий на софт, процессов, контрактов… и связей всего этого хозяйства друг с другом.
CI характеризует каждую единицу инфраструктуры в разумных деталях.
Если это сервер, то в документации записано, что он «такой-то модели», «имеет такой-то IP», имеет связь с такой-то СХД, привязан к такому-то контракту и так далее. В общем это отдельная тема.
Если говорить о Release Management. Слышал о нем, как части ITIL… не готов прокомментировать. Ретируюсь :)
Да, в маломальски средней компании уже можно использовать и Change Windows и апруверов и Disaster Recovery.
Что мне нравится в ITIL — это логичность. До любого процесса можно дойти самостоятельно и внедрить без боли. Поэтому, когда знакомишься с методиками, в голове возникает только одна мысль: «Хм, Ну да. А что можно иначе?»… тем и обоснована её популярность.
Естественно, Change Management ради Change Management — это бред, и очень хорошо, когда это понимают и руководство и технари. Главное — чтобы работа шла хорошо.