13 февраля 2009 года была выпущена версия Python 3.0.1
Это был первый минорный релиз после выпуска Python 3.0, посвященный исключительно починке дефектов, обнаруженных в предыдущей версии. И начало новой эпохи.
Честно говоря, я в то время и слыхом не слыхивал о Питоне (Пайтоне, Путоне), ведь был Perl 5.10, который вполне себе неплохо развивался, обладал огромным коммьюнити и набором библиотек на все случаи жизни в CPAN, TIMTOWTDI давал некоторую возможность для творчества и самовыражения, а Ларри Уолл рассказывал про идеи для Perl 6. И кто бы мог подумать, что спустя 15 лет вместо Perl 6 будет какой-то Raku, о котором мало кто слышал, Perl 5 уйдет в тень, а Python станет одним из самых популярных языков программирования, несмотря на родовую травму в виде GIL. И хоть идут попытки разной степени успешности сделать Python реально многопоточным, ему на пятки наступают всякие Go и компания, которые во многих вопросах и архитектурных аспектах более продуманные и быстродействующие.
А ведь раньше на Perl писали целые большие проекты и продукты... А сейчас целиком на Python написан, наверное, самый большой open-source проект в мире - Openstack.
Впрочем, также есть истории языков типа Rust и Ruby, которых величали не иначе как "убийцы <подставить название ЯП>", и где они сейчас? Один C живее всех живых и пользуется постоянным спросом, C++ цветет и пахнет, да и Java от них не отстает.
Из IT в стройку: Как айтишники из Москвы открыли современную ремонтную компанию в Москве и сколько это приносит1
В апреле 2023 года мы запустили необычный для нас проект - ремонтный сервис нового формата. Первого клиента нашли только в начале лета, но уже с первого проекта удалось достичь запланированной прибыли. Расскажу, как мы создали современную компанию для поколения "новых денег", которые не готовы к тому, что прораб будет класть половину стоимости ремонта себе в карман, а сроки растягиваются без ограничений и почему это оказалось прибыльным бизнесом.
Как всё начиналось
Конец 2022 года. Я работал менеджером проектов в крупной IT-компании, мой друг Антон - тимлидом в другой известной технологической компании, а Дима занимал позицию backend-разработчика в третьей. У всех стабильные зарплаты, интересные проекты - жизнь шла своим чередом, пока Антон не решил купить квартиру в новостройке.
После долгих поисков он остановился на 85-метровой квартире в ЖК около метро Саларьево - современный комплекс с подземным паркингом и зелёным двором. Как типичный программист, к поиску ремонтников он подошёл педантично: изучил десятки предложений, провёл собеседования с кандидатами. В итоге выбрал бригаду с Авито с "15-летним опытом работы".
За время ремонта у Антона мы с Димой часто приезжали к нему - помочь, посоветовать, и просто поржать над очередными косяками строителей. У нас обоих за плечами был серьёзный опыт управления командами, внедрения процессов, автоматизации и контроля качества. И знаете что? Нам казалось, что главное в ремонтном бизнесе - это грамотный менеджмент и организация процессов. И на самом деле, все примерно так и есть.
День когда мы решились
Если честно, мысли о собственной ремонтной компании появились у нас задолго до этого случая. В IT-тусовке часто шутят, что в России есть три верных пути: вебкам, айти и стройка. И мы, насмотревшись на хаос в ремонтной сфере, не раз обсуждали возможность открытия своей “фирмы”.
Мы выделили основные проблемы, которые должны были исправить с помощью своего сервиса
Первое - это постоянно растущие сметы и "задранная стоимость" на работы. Ну вы серьезно? Почему для меня ремонт в квартире должен чем-то отличаться от заказа носков на Вайлдберриз? Почему-то там нет такого, что цена носков может вырасти в 2 раза за время доставки. А тут начальная смета в 1 миллион превратилась почти в 1,7! И каждый раз это "ой, тут стены кривые", "ой, а тут придется докупить", "ой, а это мы не учли".
Второе - это бесконечно растущие сроки. Это еще хуже. Как люди с опытом в менеджменте, мы прекрасно знали, что растущие сроки – это всегда раздолбайство управления и ленивые рабочие. Но тут было чуть посложнее, об этом чуть позже. У Антона обещали сделать за 4 месяца, а в итоге растянули на 8.
Третье - хитрые прорабы. Это вообще отдельная история. Когда прораб говорит "давайте я сам закуплю материалы, у меня скидки", знайте - он накинет сверху процентов 30-40. А еще есть "срочные работы", которые почему-то не были учтены в смете. И конечно, вечная классика - экономия на материалах: заказываешь одно, а привозят что-то попроще, но по той же цене.
Целевая аудитория
А параллельно с этим мы определили нашу целевую аудиторию. Чтобы выделиться на конкурентном рынке, мы решили ориентироваться на молодых IT-специалистов и представителей “современных” профессий, живущих в Москве в возрасте 30-40 лет. Тех, кто покупает квартиру в новостройке и привыкших к хорошему сервису. Кто не готов, что его будут водить за нос и разводить на деньги.
Что с ценой?
При этом очень важно было держать цены НИЖЕ, чем у других компаний, иначе на рынке просто не выжить. В премиум сегмент нужен "пропуск" в виде большого количества работ для определенного типа клиентов, поэтому нам было понятно, что "брать" много - пока что, непозволительно. Но мы нашли способ: автоматизация процессов, прямые поставки материалов, четкое планирование работ и никаких скрытых накруток. Но несбыточной мечтой это покажется только обывателю: на самом деле сервис и правда должен быть таким, вообще любой.
История первого заказа летом 2023 года
А теперь самое интересное - наш первый заказ. Это была отдельная эпопея. Начало лета 2023, звонок от потенциального клиента.
Первый клиент оказался прямо "в яблочко" - тоже айтишник (пришедший из первой контекстной рекламы в яндексе запущенной на 20 тыс.), работал в крупной компании, купил двушку в панельке 80-х годов. Причем достаточно убитую - стены местами с дырками, старый паркет, трубы помнящие еще Горбачева... Но нам, если честно, даже повезло что первый объект был не новостройкой. На старом фонде учиться легче - там хотя бы есть на что посмотреть, в отличие от новостроек, где все "сюрпризы" спрятаны в голых стенах.
Дырка в стене была ДО демонтажа. Клиент купил квартиру с "убитым" ремонтом подешевле, в надежде сэкономить
Как мы мастеров искали
Начали с поиска бригады. Вот тут был первый холодный душ - оказалось, что найти классных специалистов без своей наработанной базы очень сложно. Мастера хорошего уровня либо уже при деле, либо просят космос. А те, кто сразу соглашается - ну, вы понимаете. За две недели провели больше 10 собеседований (назовем их так😊). Причем процесс собеседования мы сразу сделали "как в айти" - тестовые задания, проверка портфолио, разбор технологий работы. Бригадиры были в шоке - некоторые прямо уходили с собеседований, когда мы начинали распрашивать про технологии укладки плитки и показывали фотографии косяков с объектов с форумов.
В итоге нашли бригаду - два брата, которые до этого работали в крупной ремонтной компании, но ушли потому что устали от "серых" схем – по отношению К НИМ ЖЕ. В основном - задержки з/п и прорабы.
В том же санузле, но уже после демонтажных и некоторых черновых работ. Братья очень помогли нам с первым ремонтом, кроме этого, они дали нам контакты проверенных рабочих, которые впоследствии делали ремонт вместе с ними
Купили первый комплект инструмента - это отдельная история на 100 тысяч рублей. Ещё сразу купили свою тепловую пушку - это из необычного. Большинство компаний привлекают "потолочников" на субподряд. Мы захотели сразу начать формировать свой инструментарий для будущих сотрудников. Зато потом эта закупка очень помогла - не зависели от того, что принесет с собой бригада. Позже, когда начали расширяться купили свою штукатурную станцию. Это, на удивление, было самой выгодной покупкой.
Первые сложности
Начали ремонт. И тут поехало... Первый сюрприз - когда начали снимать старую штукатурку, оказалось что стены буквально рассыпались. Плюс под старым линолеумом в коридоре нашли деревянный пол с насыпью под ним.
Тут был первый серьезный разговор с заказчиком. Объяснили ситуацию, показали все фотки, рассказали что сколько будет стоит в соответствии с прайс-листом. Тут очень помогло то, что мы сразу взяли за правило - фотографировать вообще все. Каждый этап, каждый слой, каждую трубу.
С материалами тоже было весело. Первый месяц я лично объездил все крупные строительные магазины в радиусе 30 км. Искал поставщиков, договаривался о скидках. Помню, как чуть не купили партию плитки по "супер-выгодной" цене, а потом выяснилось что это условно "второй сорт" - брак, который продают через "серые" схемы.
Cделали систему закупок: (Первый заказ полностью сделан из материалов, купленных в Петровиче и на маркетплейсах). Бригада присылает список - мы проверяем цены у 3-4 поставщиков и заказываем где дешевле.
Мы сразу внедрили систему ежедневных фото-отчетов и еженедельных созвонов. Плюс сделали чат в телеграме, куда скидывали все чеки, все накладные, все фотки. Такая прозрачность очень помогла - клиент видел, что мы не химичим с ценами и не пытаемся на нем нажиться.
В итоге сделали.
Братья советовали нам недостающих специалистов по ходу ремонта и постепенно, укладываясь в срок мы сдавали клиенту новый и новый этап. Честно, это было не так сложно как казалось в начале, но нужно понимать, что на самом деле, проблем по ходу ремонта и мелких трудностей было ОЧЕНЬ много, просто мы как люди привыкшие, понимали что сейчас это и есть наша работа , за которую нам платит клиент - взять на себя все заботы по ремонту. Но серьезных форс-мажоров не возникало, максимум понервничали, когда внесли предоплату потолочникам, которых нашли по объявлению, после чего они явно начали задерживать сроки, но в итоге, все обошлось. Нам и до этого было ясно, что чем быстрее мы соберем свой , хотя бы, небольшой штат, тем лучше и выгоднее. Но для этого надо быть уверенным в постоянном потоке заказов, что мы на тот момент, не могли себе позволить.
Главное - мы поняли как надо и как не надо. Все закупки только через нас. Все договоренности - только в письменном виде.
По деньгам первый проект получился условно в ноль - не считая наших вложений в инструмент и рекламу. Но мы получили бесценный опыт, наработали связи с поставщиками (если это можно назвать так пафосно) и главное - поняли, что наша модель рабочая, хотя на тот момент не были в этом до конца уверены. Наши сомнения развеяло лето 2023 года.





Наша первая работа, которую нам помогли закончить "братья", советуя недостающих мастеров на каждый этап работ. Цена работ для заказчика вышла 750 000 рублей. Летом 2023 года, за аналогичный объём работ авитовские бригады просили до миллиона(!)
Сайт и маркетинг или как мы общаемся с клиентами ещё до первого звонка
Кстати, про сайт. Первую версию мы сделали за пару вечеров на Тильде - максимально простую: фотки, цены, контакты. Знаете что? Он у нас до сих пор такой – но с значительно изменённым UI/UX. Я иногда ловлю себя на мысли - вот мы же, можем сделать что-то крутое, с личным кабинетом, онлайн-сметами... Но потом смотрю вордстат, статистику и думаю - а зачем? Клиенты находят нас, звонят, все работает. Иногда лучшее решение - самое простое.


На главной странице "в лоб" о том кто мы, наши конкурентные преимущества, специализация и примеры работ


Сразу "ярко" заявляем о действующих скидках. Кроме этого, простым текстом пытаемся общаться с клиентом и убедить его в нашем сервисе, пока что, не общаясь с ним лично - конверсия в лиды увеличилась значительно, но важно, чтобы все предложения были реальны
А вот ворд стат. За последний месяц нас искали 680 раз не считая статистики переходов по прямой ссылке. Доказательство того, что дорогой сайт не нужен. Наш стоит 6 000 рублей в год, а сделан за 20 часов
Примеры лучших работ как маркетинговый инструмент




Оставляли подобные фото с примерами работ и вотермаркой в отзывах к жилым комплексам. Отличный маркетинговый инструмент - сразу определяем нужную ЦА и бесплатно заявляем о себе. Точно знаем, что минимум один клиент был из отзывов яндекс - поэтому работает
Как мы масштабировались и разбирались в проблемах ремонта
Теперь про то, как мы начали разбираться в проблемах ремонта и потихоньку расти. Знаете, за этот год мы много думали - почему вообще ремонтные компании задерживают сроки и не могут сделать работу по первоначальной цене? И нашли несколько интересных моментов.
Первое - сроки. Тут даже копать глубоко не пришлось - сам рынок сформирован так, что клиенты просто привыкли к задержкам. "А, ну это ремонт, тут всегда так" - классическая фраза. Благо тут нам помог опыт организации процессов из айти. Четкие спринты, ежедневные отчеты, календарный план. Работает как часы, если не филонить.
Второе - вечно растущая цена. Вот это было сложнее. В новостройках еще можно точно посчитать, а во вторичке... Но благодаря наработкам этот вопрос стал гораздо яснее. При правильно организации процессов, непредвиденные работы лучше оплатить из своих средств, чем терять клиента. Только так и делается сервис.
Третье - больная тема - воровство на материалах. Тут мы конкретно закрутили гайки. Завели строгий учет, до последнего мешка штукатурки. Прорабам сразу сказали - любая жалоба от клиента на нечестность - это конец сотрудничества. Знаете что самое смешное? Когда начали работать честно, оказалось что маржа все равно хорошая. Просто многие привыкли что надо обязательно накручивать еще и еще.
Неприятные особенности прозрачного сервиса
Большинство компаний, которые начинают работать честно, быстро сдуваются. Потому что сам потребитель привык к плохому сервису. Приходишь к клиенту, говоришь "мы все сделаем четко по смете и в срок", а он смотрит с недоверием - "да ладно, так не бывает". Сейчас в 2024-м ситуация получше, но рынок все еще очень консервативный.
Продвижение или как мы брали “Новую Москву”
Наш любимый Прокшино в Новой Москве - в 2024 году, это самый перспективный район в котором покупатели - наши потенциальные клиенты
Расти начали потихоньку. Сначала сделали специальные цены для новой Москвы - там как раз много новостроек, где мы хорошо научились работать. Потом пошли заказы по рекомендациям. Когда я говорю “пошли” заказы нужно понимать, что это 1-3 заказа в месяц стабильно, что на самом деле, тогда казалось не мало. С рекламой экспериментировали забавно - оставляли визитки в подъездах (да, просто старые добрые визитки!), ставили рекламные ящики у офисов продаж в дни выдачи ключей.
Был случай, когда на одном ЖК поставили такую стойку, а через неделю риелтор оттуда сам позвонил и предложил взять себе процент, если клиент пойдет к нам.
Сейчас берем 2-5 заказов в месяц, (летом было 5 в месяц, если разделить). Большинство клиентов приходят по рекомендациям. Штат за год работы постепенно собрали свой. Трудоустроено 14 сотрудников. Если их не хватало (как летом), привлекали мастеров с которым уже работали раньше, по договору ГПХ. Просили всех регистрировать самозанятость или ИП – это было тяжело, но зато честно платим налоги по Доходы – расходы.
Как устроен процесс
Знаете, что самое сложное в ремонтном бизнесе? Нет, не поиск клиентов и не работа с материалами. Самое сложное - это выстроить систему, которая будет удовлетворять запросы клиента и при этом позволит компании зарабатывать. Мы долго думали над этим и придумали несколько интересных решений.
Начнем с оплаты. Если посмотреть на московский рынок, там забавная система - вроде бы без предоплаты, но это только за первый, самый дешевый этап. А потом - бац, и клиент должен внести 50% от всей суммы. И попробуй не внеси - бригада уйдет на другой объект. Мы сделали иначе: разбили весь ремонт на этапы (их получилось 12 для капитального ремонта), и берем предоплату только за текущий этап. То есть клиент всегда понимает, за что именно платит, и может контролировать процесс.
С договорами тоже интересно получилось. Сначала делали один стандартный, а потом поняли - люди разные, запросы разные. Сейчас у нас три варианта: просто на работы (для тех, кто сам хочет закупать материалы), на работы плюс материалы (самый популярный), и полный пакет с дизайн-проектом. Кстати, про дизайн - мы не держим штатных дизайнеров, работаем с фрилансерами. Так получается и дешевле для клиента, и качество выше - каждый дизайнер специализируется на своем стиле.
Расчёт стоимости
Расчет стоимости работ - отдельная история. Когда начинали, было очень сложно. На рынке нет четких цен - один мастер берет 3 тысячи за квадрат стяжки, другой - тысячу, третий вообще говорит "ну давайте посмотрим по факту". Сначала работали по среднему прайсу, но часто уходили в минус по отдельным этапам - то бригада дороже встанет, то материала больше уйдет. Сейчас, когда появились постоянные сотрудники, стало проще - мы точно знаем их расценки и можем давать фиксированную цену.
Материалы
Выяснилось, что в крупных магазинах часто дешевле в сравнении с рынками стройматериалов, особенно если ловить акции. Плюс появились маркетплейсы - там вообще красота по ценам. И главное - полная прозрачность, клиент сам видит все позиции. Если находим материал дешевле - возвращаем разницу. Был случай, когда на керамограните сэкономили клиенту почти 30 тысяч - просто потому что, нашли ту же плитку в другом магазине по акции.
Как работаем сейчас
Сейчас берем 2-5 заказов в месяц, зависит от сезона и сложности объектов.
Процесс обкатан до мелочей: сначала выезд на замер, потом предварительная смета. Если клиента все устраивает - детальный расчет и договор. Дальше начинается самое интересное - согласование материалов, закупки, работа.
Особенности продвижения и подводные камни
С продвижением интересно получилось. Сначала, как все, полезли на Авито. И знаете что? Не зашло. Там своя специфическая аудитория и конкретно у нас, с Авито “ не пошло”.
Свежий пример страницы с авито в категории "Ремонт квартир". Как клиенты определяются с подрядчиком среди тысяч однотипных объявлений - хороший маркетинговый вопрос, который мы решаем, после чего полноценно "зайдём" на авито
Пробовали контекстную рекламу яндекс - тоже так себе результат. Клики дорогие, конверсия низкая. Зато отлично зашла таргетированная реклама в Instagram* (*запрещен в РФ) и реклама в районных пабликах ВКонтакте. Особенно в группах новостроек в ТГ - там как раз наша целевая аудитория.
Но главный канал - сарафанное радио. Причем работает оно интересно. Всегда знаешь , от кого пришли заказчики и проще выстраивать коммуникацию. Есть клиент - он доволен, рассказал коллегам - и понеслось. За три месяца получили еще два заказа от сотрудников той же компании. Выходит такой “корпоративный ремонт”)))
Были, конечно, и провалы в продвижении. Пытались работать с риелторами - предлагали им комиссию за клиентов. Не пошло - у них свои схемы, свои бригады. Пробовали давать рекламу в лифтах, входных группах - тоже мимо, ни одного обращения, но тут скорее из-за того что эта реклама буквально на день.
ИТОГ
Сейчас мы существуем уже чуть больше года и в целом смотрим на ремонтный рынок не так, как раньше. За это время мы сделали несколько важных заметок для себя:
Оказывается, большинство проблем в ремонте - это не технические сложности, а банальная организация процессов. Когда все четко спланировано и каждый знает что делать - даже самый сложный ремонт идет как по маслу.
Мы поняли, почему многие компании "химичат" с ценами и сроками - просто потому что не умеют нормально считать и планировать. Когда все процессы выстроены правильно, можно работать честно и все равно оставаться в плюсе.
Самое сложное - это не найти клиентов или научиться делать ремонт. Самое сложное - это переломить привычку рынка работать "по-серому". И заказчики, и исполнители настолько привыкли к непрозрачным схемам, что честный подход вызывает удивление.
Мы до сих пор учимся. Каждый объект - это новый опыт и новые вызовы (особенно по части коммуникаций с клиентами). Но главное - мы видим, что наша модель работает и пока что, нам удается держать ценник немного ниже рыночного, за счёт того что до сих пор не имеем в найме маркетологов, IT, отдела продаж и менеджеров по продажам. Стараемся нанимать именно рабочих, все остальное можно отдать на аутсорс.
Уважаемые пикабушники, были рады составить для вас эту статью! С любовью, СК Комната
Часть 3. Внезапная. А зачем мы всё это делаем?
Продолжение поста Какую задачу будет решать веб-приложение?
Если кому-то что-то непонятно, спрашивайте. И наоборот, если видите, что я несу бред - поправляйте.
Не успели мы написать и строчки кода, как в комментариях возник главный вопрос жизни, Вселенной, разработки и всего такого. И я нифига не шучу, абсолютно каждая программа для своего написания ставит такой вопрос. Если мы пишем некую программу для себя, то типичным ответом будет - мне так захотелось. В конкретно этой серии постов, которую я и писать изначально не собирался, я решил разобрать веб-разработку по шагам на максимально простом примере, но который бы делал что-то реальное и которым можно было бы пользоваться. Поскольку на днях вышел линух 6.7, можно считать это посвящением ему, поскольку Линус тоже начинал свою разработку с целью обмена сообщениями. При разработке ПО же на коммерческой основе этот вопрос будет основным и он точно так же будет возникать в самом начале. В компаниях на него обычно отвечает Архитектор или Тимлид, или кто там решает, а зачем, собственно?
Если более детально, то я увидел некую проблему (затруднённость обмена частными посланиями на пикабу), придумал, как её решить посредством ПО и решил это сделать. Также был вопрос, а почему я собираюсь это делать именно так? В данном случае - потому что, опять же, я так решил. В случае коммерческой разработки любое такое решение нужно будет обосновывать, потому что оно будет стоить от очень больших до гигантских или даже невероятных сумм. Потому что абсолютно любое решение имеет как плюсы, так и минусы. Всё как в любой другой инженерной и прочей системе, и как вообще всегда в жизни.
А, может, можно сделать как-то иначе, лучше? Конечно, можно. Всё всегда можно сделать иначе, особенно в разработке ПО. Но, каждое решение см. абзац выше. Поэтому я пока собираюсь делать по написанному во втором посте алгоритму, поскольку пока никто не предложил, как можно в нём что-то улучшить, существенно что-то не ухудшив. Зато, как было замечено, этот алгоритм является частным случаем другого алгоритма, на базе которого работает 99% обмена данными в нынешних компьютерных системах. Такой вот ещё один внезапный учебный плюс нарисовался :)
Так что, в итоге - умение отвечать на этот вопрос, в области ИТ - одно из самых высокооплачиваемых. И, чтобы научиться на него отвечать, нужны 2 вещи: здравый смысл и очень хороший опыт в программной инженерии, который я и собирался немного раскрыть в последующих постах.
Какую задачу будет решать веб-приложение?
Продолжение поста Пишем и запускаем веб-приложение
Раз есть интерес, начнём!
Если кому-то что-то непонятно, спрашивайте. И наоборот, если видите, что я несу бред - поправляйте.
На пикабу нельзя, ну или я не знаю, как, послать друг другу сообщение так, чтобы его не увидели все. Как это можно было бы сделать? Например, так: один пользователь сообщает другому, в комментах, обычным образом, код, на который нужно отправить сообщение (этап 1). Второй переходит по адресу с этим кодом и оставляет там сообщение (этап 2). А также запоминает второй код, который потом тоже сообщает в комментах первому. Первый снова идёт на этот сервис и, по полученному от второго коду, читает сообщение (этап 3). Что-то типа установки tcp сессии, если кому интересно :)
Зачем нужны эти коды? Первый код будет гарантировать второму пользователю, что сообщение точно будет адресовано первому. А второй код будет позволять первому пользователю выбрать сообщение именно второго. Почему? Потому что, сообщив на этапе 1 общедоступный код, первый пользователь может получить сообщения от кого угодно, ведь сервис предполагается общедоступным. Сервис будет генерировать уникальный второй код при каждом сохранении каждого сообщения, соответственно, получив через комменты второй код, первый пользователь будет точно знать, какое сообщение направлено конкретным юзером пикабу. Тут, конечно, не обязательно пикабу, главное, что можно обменяться общедоступным способом двумя кодами и, посредством их, получить частное сообщение, никому, кроме адресата, уже недоступное.
А откуда будет браться первый код? Его тоже будет генерировать сервис, при регистрации. Т.е., для получения таких сообщений получателю нужно будет зарегистрироваться на этом сервисе. Регистрация будет позволять получателю видеть отправленные только ему сообщения. Отправителю регистрироваться не нужно. Для защиты от спамов и ддосов желательно будет после получения нужного сообщения делать первый код недействительным и, для возможности получения нового сообщения, нужно будет сгенерировать новый код 1 (временный URL).
Итак, что должен будет делать этот веб-сервис:
Регистрировать пользователей-получателей сообщений.
Генерировать им некий код, лучше всего - уникальный временный URL, по которому будет доступно поле ввода сообщения (код 1).
Сохранять полученные сообщения для последующего показа их получателю.
Для отправителя генерировать код сохранённого сообщения (код 2).
Показывать получателю конкретное сообщение по коду 2.
Удалять все эти коды и сообщения по некоторым правилам.
Пишем и запускаем веб-приложение
Задумал я написать одну полезную, на мой взгляд, для пользователей пикабу штуку, и, подумал, что было бы, возможно, неплохо разобрать её написание для всех, интересующихся этим. Вопросы, которые нужно будет разобрать:
Что такое веб-приложение.
Его создание. Писать буду на Perl + Dancer2.
Создание БД и взаимодействие с ней. PostgreSQL.
Запуск приложения и БД в docker посредством docker-compose.
Запуск приложения на реальном хостинге и организация доступа к нему посредством настройки DNS-записей.
Для желающих - хранение кода приложения в git.
Собственно, если кому-либо это интересно, черканите в комментариях.
Разворачиваем сеть на RHEL8-based хостах (копия с Хабра)
1. Предисловие
Развертывание ИТ-инфраструктуры с нуля — задача интересная и трудозатратная. Особенно, когда речь не о постепенном развитии (как это часто случается при поступательно-линейном росте бизнеса и, соответственно, его потребностей), а о куда более сжатых сроках, например, при открытии филиала или обособленного подразделения (другой вариант — необходимость в короткие сроки развернуть инфраструктуру для тестирования), где важную роль играет организация сети.
Конечно, первоначальная установка и настройка — это всегда полевая работа: монтаж СКС, сетевого оборудования и серверов; конфигурирование DHCP и организация удалённого доступа; иногда — заведение VLAN-ов.
Итак, представим, что первичная настройка сети проведена: монтаж СКС осуществлён, DHCP выдал всем устройствам IP-адреса, удалённый доступ до сети филиала (или обособленного подразделения) в наличии, на одни сервера заведены 2 (или более) физических соединения для организации BOND-ов, на другие поданы транковые соединения с несколькими VLAN-ами и т.д.
Список IP-адресов серверов сведён в таблицу и доступ по SSH в наличии. Если размер списка невелик (например, до 3-5 единиц), то ручная настройка покажется неплохим вариантом, хоть и отнимет какое-то время.
А если список содержит, например, 10 (или более) хостов, на части из которых необходима уникальная сетевая конфигурация (разделение trunk-соединения на vlan-ы, виртуальные bridge-ы, etc)? Тут уж временные затраты существенно возрастают.
Но нет необходимости тратить время на рутину, если готовое решение есть и ожидает вас ниже (со ссылкой на guthub-репозиторий в конце публикации).
1) Ansible. Весьма популярен (хотя кому-то ближе Puppet, Chef или Salt). Применяется для доставки контента/команд на целевые хост-системы.
2) Командная оболочка Bash. Присутствует во всех linux-системах. В рамках решения используется как для создания оболочки над Ansible, так и для отложенного выполнения операций (если конкретнее — отката сетевых настроек по таймеру) на целевых хостах.
3) Perl 5. Отличный инструмент в умелых руках. С помощью этого ЯП написан функционал генерации ifcfg-файлов на основе текстового конфига (т.е. Perl задействован только на ansible-хосте).
4) Network-scripts. Хоть и не включён в минимальный вариант установки ОС семейства RHEL8, но является проверенным средством настройки сетевой подсистемы.
Приложение «conf_int_ipv4_via_network_scripts» (ansible-приложение) представляет собой набор perl/bash-скриптов и файлов конфигурации (inventory-file, etc). Хотя и является составной частью репозитория «ansible_helpers», но имеет автономный характер.
5.1. Структура директорий1. Корневой раздел (условно обозначим «../»). Содержит все основные скрипты поддиректории.
2. Директория с дополнительными конфигами («../additional_configs»). Содержит дополнительные файлы конфигурации, с помощью которых возможно задать содержание resolv.conf (указать NS-сервера), таймаут отката конфигурации и опцию удаления неиспользуемых ifcfg-файлов на стороне целевых хостов.
3. Директория с playbook-ами («../playbooks), которая в свою очередь имеет свои подразделы:
3.1) dyn_ifcfg_playbooks. Тут динамически генерируеются уникальные для каждого хоста плейбуки, ifcfg-файлы и настройки dns (resolv.conf).
3.2) ifcfg_backup_from_remote. Содержит резервные копии сетевых настроек с привязкой к дате («history»), текущую конфигурацию до изменения («now») и полную информацию о сетевых интерфейсах («network_data»).
3.3) ifcfg_tmplt. Как следует из названия, хранит шаблоны ifcfg-конфигураций, на основе которых формируются уникальные для каждого inventory-хоста настройки сети.
3.4) scripts_for_local. Хранит скрипты для исполнения на ansible-хосте. В данном случае подразумевается скрипт преобразования сырых данных в файлы c информацией о сетевых интерфейсах (размещаются в директории «../ifcfg_backup_from_remote/network_data»).
3.5) scripts_for_remote. Скрипты для исполнения на удалённых хостах. В данном случае он один — rollback_ifcfg_changes.sh (скрипт отката к предыдущим настройкам сетевой подсистемы).
6) tasks. Используемые в плейбуках файлы задач.
4. «../run_history». Логи запуска/исполнения сценариев приложения.
1. «../conf_network_scripts_hosts» — inventory-файл приложения.
2. «../config» – основной файл конфигурации приложения. Также имеется файл «config_examples» с примерами настроек. Для получения имён сетевых интерфейсов и соответствующих им MAC-адресов, требуемых при заполнении файла «config», необходимо запустить скрипт «just_run_ifcfg_backup.sh» и ознакомиться с файлом «../playbooks/ifcfg_backup_from_remote/network_data/inv_hosts_interfaces_info.txt».
3. «../additional_configs/config_del_not_configured_ifcfg» - задаёт действие относительно тех ifcfg-файлов, которые не сконфигурированы в «../config». Если в «config_del_not_configured_ifcfg» вписать адрес хоста, то ansible-приложение удалит на remote-хосте все ifcfg-файлы, выключит соответствующие интерфейсы («ifdown») и удалит линки (через «ip link delete»), но только те, которые относятся к bond/bridge и vlan-интерфейсам (например, eth0.100). Настройка будет полезна в случая, когда, например, требуется переименовать какое-либо bond/bridge-соединение.
4. «../additional_configs/config_temporary_apply_ifcfg» - тут возможно задать таймаут (как общий, так и для различных inventory-хостов индивидуально) отката к предыдущим настройкам.
5. «../additional_configs/dns_settings». Предоставляет возможность выставить настройки dns индивидуально для каждого inventory-хоста.
1. «install_network_scripts_and_configure_network.sh» - производит бэкап ifcfg-файлов, устанавливает «network-scripts» (если функционал не установлен ранее), проверяет статус сервиса «network.service» (если не запущен, то стартует), исполняет скрипт «generate_dynamic_ifcfg.pl» и применяет изменения сетевых настроек (заданных в файле «config») на удалённых хостах (если, конечно, настройки корректны).
2. «just_install_network_scripts.sh» устанавливает «network-scripts» (если функционал не установлен ранее).
3. «just_run_ifcfg_backup.sh» - производит бэкап ifcfg-файлов.
4. «check_network_scripts_serv_is_started.sh» - проверяет статус сервиса «network.service» (если не запущен, то стартует).
5. «check_ifcfg_without_apply.sh» - проверяет корректность сетевых настроек (файл «config»).
6. «apply_temporary_ifcfg.sh» - временно применяет сетевые настройки. Таймаут отката задается в конфиге «../additional_configs/config_temporary_apply_ifcfg».
7. «apply_immediately_ifcfg.sh» - немедленно применяет новые сетевые настройки, если, конечно, они изменились с момента предыдущего запуска (в т.ч. если были внесены какие-либо изменения вручную на удалённых хостах).
5.4. Описание основного файла конфигурации (UPD 2022-12-19)
Каждая строка в файле представляет собой набор параметров, разделённых символами "пробел/табуляция":
1) INV_HOST. Должен соответствовать одному из хостов inentory-файла "conf_network_scripts_hosts".
2) CONF_ID. Уникальный идентификатор сетевого интерфейса (или набора сетевых интерфейсов) в рамках каждого inventory-хоста.
3) CONF_TYPE. Определяет тип конфигурации для конкретных сетевых интерфейсов. Возможные значения:
3.1) just_interface (обычный интерфейс);
3.2) interface-vlan (интерфейс, поднимаемый в рамках транкового соединения, из которого каждый vlan возможно выделить по vlan-идентификатору);
3.3) virt_bridge (виртуальный мост);
3.4) just_bridge (обычный мост);
3.5) bridge-vlan (мост поверх vlan-интерфейса);
3.6) just_bond (конфигурация агрегированного канала, состоящего из 2-х и более физических соединений);
3.7) bond-vlan (vlan-итерфейс поверх bond-соединения);
3.8) bond-bridge (соединение типа "мост" поверх bond-соединения);
3.9) bond-bridge-vlan (соединение типа "bridge-vlan" поверх bond-соединения).
Каждому из этих значений соответствует свой набор шаблонов ifcfg-файлов (директория "ifcfg_tmplt").
4) INT_LIST. Список сетевых интерфейсов (разделённых запятой), используемых в рамках конкретного типа конфигурации (CONF_TYPE).
5) HWADDR_LIST. Список MAC-адресов, соответствующих сетевым интерфейсам из INT_LIST. Для CONF_TYPE=virt_bridge параметру необходимо присвоить значение "no".
6) VLAN_ID. Идентификатор VLAN. В случае, если речь не про vlan, то должен иметь значение "no".
7) BOND_NAME. Используется только для CONF_TYPE, равных "just_bond, bond-vlan, bond-bridge, bond-bridge-vlan". В остальных случаях необходимо выставлять значение "no".
8) BRIDGE_NAME. Используется только для CONF_TYPE, равных "virt_bridge, just_bridge, bridge-vlan, bond-bridge-vlan". В остальных случаях необходимо выставлять значение "no".
9) IPv4_ADDR_OPTS. Опции IPv4. Возможные значения: строка вида "ipv4,gateway,netmask" (для использования статической адресации) или "dhcp" (для получения ip-адреса и прочих параметров через DHCP).
10) BOND_OPTS. Настройки агрегирования для bond-соединения. Возможные значения: "def" ("mode=4,xmit_hash_policy=2,lacp_rate=1,miimon=100") или иное сочетание параметров, разделённых запятой.
11) DEFROUTE. Флаг "маршрут по умолчанию". Для конкретного inventory-хоста должен быть только один.
Чтение и обработка файла "config" происходит посредством Perl-скрипта "generate_dynamic_ifcfg.pl", который осуществляет ряд проверок конфигурации (в т.ч. и используя информацию, полученную посредством «just_run_ifcfg_backup.sh»), инициирует приостановку исполнения сценариев на удалённых хостах, если данные в "config" некорректны, формирует необходимые наборы ifcfg-файлов для каждого inventory-хоста, а также создаёт персональные для каждого хоста ansible-playbook-и (в директории "dyn_ifcfg_playbooks"), если сгенерированные файлы интерфейсов отличаются от текущих.
6. Постскриптум
Ссылка на репозиторий
В README-файле перечислены как уже готовые приложения, так и те, статус которых варьируется от «в процессе» до «есть в планах».
Спокойного кодинга всем причастным!
=====================
Статья на Хабр
Чем прочитать данные из SNMP и записать в БД MySQL?
Собственно, вопрос названии темы. Есть некоторое оборудование с датчиками температуры и атмосферного давления, инфа отдаётся по SNMP. Требуется значения датчиков получать по крону и записывать в базу данных. Нашёл Perl-скрипт, который, судя по описанию, должен это делать. Создал базу, пользователя, предоставил привилегии, в изначальном скрипте подставил нужные значения, но он завершается с ошибкой can't execute request. Сам скрипт:
#!/usr/bin/perl
use strict;
use warnings;
use DBI;
use Net::SNMP;
# Параметры подключения с базе
my $database_login = 'pogoda';
my $database_passwd = 'Pogoda123';
my $database_name = 'pogoda';
# Подключаемся к базе
my $dbh = DBI -> connect("DBI:mysql:$database_name;host=localhost;", $database_login, $database_passwd) || die $DBI::errstr;
# Что будем оправшивать
my $snmp_host = '10.10.35.100'; # IP или hostname
my $snmp_community = 'public'; # SNMP Community
#Температура
my $snmp_oid_temperature = 'iso.3.6.1.4.1.17095.1.2.9.0'; # OID для опроса
#Атмосферное давление
my $snmp_oid_pressure = 'iso.3.6.1.4.1.17095.1.2.17.0'; # OID для опроса
# Пытаемся читать значение
# В -varbindlist должна быть ссылка на массив OID'ов
# В $result будет ссылка на хэш вида: OID => Значение
my $snmp_session = Net::SNMP->session(
-hostname => $snmp_host,
-community => $snmp_community,
-version => 1, # Явно указываем версию протокола
) or die "can't connect";
my $result = $snmp_session->get_request(-varbindlist => [$snmp_oid_temperature,$snmp_oid_pressure]) or die "can't execute request\n";
# Печатаем результат
print "$result->{$snmp_oid_temperature}\n$result->{$snmp_oid_pressure}\n";
# Пишем значения в базу
$dbh -> do("INSERT INTO netping1 SET temperature=\"$result->{$snmp_oid_temperature}\", pressure=\"$result->{$snmp_oid_pressure}\"") || die $DBI::errstr;
Т.к. я не ни разу не программист, не могу понять почему скрипт не отрабатывает. Что не так со скриптом? Ошибку в синтаксисе perl -c не нашёл. Все дополнения Perl, на которые он ругался, доустановлены.
Или существуют ли другие способы решить исходную задачу?











